Slashdot Mirror

• Improvements to Arabic shaping which result in better layout of Arabic pages on Linux and other platforms without their own Arabic support.
• A bug was fixed which caused English text in text boxes to be displayed in the wrong direction on Hebrew pages.
• The JavaScript Debugger has gone through a major development cycle. It now sports a palette of nine views which can be rearranged within the main window, or docked in separate floating windows. It is also possible to create user defined views and commands directly with JavaScript. More details are available in the FAQ, newsgroup, or IRC channel.
• Distinct window icons on MS Windows for the different Mozilla applications
• Mozilla on Linux now has Fullscreen mode. (press F11)
• All Search entry points now your default search engine.
• Improved site compatability and rendering.
• The tab bar now has a button for creating new tabs.

Mozilla.org gets a lot of duplicate bug reports: 40-50% of a sample of bugs from April 2002 are dups. If you know how to search Bugzilla, you can get that down to 15-20%. (Knowing some jargon helps too, of course.) Unfortunately, the most widely advertised Bugzilla search tool, the query builder, is so complicated that many testers give up before finding their bug and report a duplicate.

There's a well-hidden search box on the Bugzilla front page that works a lot like Google. You can almost use it like Google, but there are several differences you should be aware of:

• Each word is matched as a substring of the summary (and several other fields). A search for 'auto compl' will match "auto-complete", "auto complete", and "autocompletion".
• Like in Google, you can use | to create disjunctions. For example, a search for 'address|location|url bar|field focus' will match "focus does not move when clicking outside of location bar". While "or" is usually unnecessary for general web searches, it is indispensible when searching for a specific bug report.
• By default, Bugzilla only searches for open bugs. If you're looking for a bug that has been reported several times, it may help to include duplicates in the search. One way to do this is to prefix the search with 'ALL ' in all caps. For example, 'ALL rename exe' will lead you to an often-reported bug (120327) that I should be helping bz to fix instead of posting this comment, while 'rename exe' will not find anything.
• If you know that the bug you're searching for is visible and popular, try adding 'votes:2' to your search. For example, 'ALL votes:2 context menu back' will find the newest flamewar-bug about the back command in the context menu among the 42 bugs that match 'ALL context menu back'. Searches that use votes:2 are several times faster than searches that include all bugs because bugzilla can start the search with an integer comparison.
• The search includes several fields, not just the bug summary (title). For example, in a search for 'mail compos focus', the word "mail" can appear in either the product name (MailNews) or the bug summary, and "compos" can appear either in a component name (Composition) or in the summary (compose, composing, etc). To restrict a search term to the summary, use '+term'.

Other useful tools for avoiding reporting duplicates include the frequently reported bugs list and #mozillazine on irc.mozilla.org. If you find yourself working in Bugzilla a lot, you can use the collect buglinks bookmarklet to get a list of bugs mentioned in a given bug report, which is useful because many bug reports include links to related bugs.

Mozilla.org gets a lot of duplicate bug reports: 40-50% of a sample of bugs from April 2002 are dups. If you know how to search Bugzilla, you can get that down to 15-20%. (Knowing some jargon helps too, of course.) Unfortunately, the most widely advertised Bugzilla search tool, the query builder, is so complicated that many testers give up before finding their bug and report a duplicate.

There's a well-hidden search box on the Bugzilla front page that works a lot like Google. You can almost use it like Google, but there are several differences you should be aware of:

• Each word is matched as a substring of the summary (and several other fields). A search for 'auto compl' will match "auto-complete", "auto complete", and "autocompletion".
• Like in Google, you can use | to create disjunctions. For example, a search for 'address|location|url bar|field focus' will match "focus does not move when clicking outside of location bar". While "or" is usually unnecessary for general web searches, it is indispensible when searching for a specific bug report.
• By default, Bugzilla only searches for open bugs. If you're looking for a bug that has been reported several times, it may help to include duplicates in the search. One way to do this is to prefix the search with 'ALL ' in all caps. For example, 'ALL rename exe' will lead you to an often-reported bug (120327) that I should be helping bz to fix instead of posting this comment, while 'rename exe' will not find anything.
• If you know that the bug you're searching for is visible and popular, try adding 'votes:2' to your search. For example, 'ALL votes:2 context menu back' will find the newest flamewar-bug about the back command in the context menu among the 42 bugs that match 'ALL context menu back'. Searches that use votes:2 are several times faster than searches that include all bugs because bugzilla can start the search with an integer comparison.
• The search includes several fields, not just the bug summary (title). For example, in a search for 'mail compos focus', the word "mail" can appear in either the product name (MailNews) or the bug summary, and "compos" can appear either in a component name (Composition) or in the summary (compose, composing, etc). To restrict a search term to the summary, use '+term'.

Other useful tools for avoiding reporting duplicates include the frequently reported bugs list and #mozillazine on irc.mozilla.org. If you find yourself working in Bugzilla a lot, you can use the collect buglinks bookmarklet to get a list of bugs mentioned in a given bug report, which is useful because many bug reports include links to related bugs.

Mozilla.org gets a lot of duplicate bug reports: 40-50% of a sample of bugs from April 2002 are dups. If you know how to search Bugzilla, you can get that down to 15-20%. (Knowing some jargon helps too, of course.) Unfortunately, the most widely advertised Bugzilla search tool, the query builder, is so complicated that many testers give up before finding their bug and report a duplicate.

There's a well-hidden search box on the Bugzilla front page that works a lot like Google. You can almost use it like Google, but there are several differences you should be aware of:

• Each word is matched as a substring of the summary (and several other fields). A search for 'auto compl' will match "auto-complete", "auto complete", and "autocompletion".
• Like in Google, you can use | to create disjunctions. For example, a search for 'address|location|url bar|field focus' will match "focus does not move when clicking outside of location bar". While "or" is usually unnecessary for general web searches, it is indispensible when searching for a specific bug report.
• By default, Bugzilla only searches for open bugs. If you're looking for a bug that has been reported several times, it may help to include duplicates in the search. One way to do this is to prefix the search with 'ALL ' in all caps. For example, 'ALL rename exe' will lead you to an often-reported bug (120327) that I should be helping bz to fix instead of posting this comment, while 'rename exe' will not find anything.
• If you know that the bug you're searching for is visible and popular, try adding 'votes:2' to your search. For example, 'ALL votes:2 context menu back' will find the newest flamewar-bug about the back command in the context menu among the 42 bugs that match 'ALL context menu back'. Searches that use votes:2 are several times faster than searches that include all bugs because bugzilla can start the search with an integer comparison.
• The search includes several fields, not just the bug summary (title). For example, in a search for 'mail compos focus', the word "mail" can appear in either the product name (MailNews) or the bug summary, and "compos" can appear either in a component name (Composition) or in the summary (compose, composing, etc). To restrict a search term to the summary, use '+term'.

Other useful tools for avoiding reporting duplicates include the frequently reported bugs list and #mozillazine on irc.mozilla.org. If you find yourself working in Bugzilla a lot, you can use the collect buglinks bookmarklet to get a list of bugs mentioned in a given bug report, which is useful because many bug reports include links to related bugs.

The infamous profile-trashing between versions bug is still present. Comments indicate that it has to be fixed before Mozilla 1.x goes out as Netscape, or Netscape won't coexist with itself.

Hold your breath and try MSDN. It's got everything about everything for MSIE, from HTML to scripting, from tutorials to reference. I'm not a big fan of Microsoft, but MSDN is truly useful. It's also a good reference for CSS2 properties, since these are thankfully the same (and reasonably well supported) on both MSIE and Mozilla.

To ensure cross-browser DHTML compatibility however, cross-reference with the Gecko DOM reference from the Mozilla project. It's DHTML for Mozilla; the model is completely different sadly but it works, and it's possible to write code that works for both MSIE and Mozilla/Gecko simultaneously with a little thought -- I learned most of what I know from Dan Steinman's excellent dynamic duo site.

If you're also using PHP, then you'll probably end up using MySQL as well. I learned most of the SQL I know simply by reading the MySQL manual. It's just as useful as the PHP Manual.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Is everybody still inventing his own application layer protocol?

Stateless, connectionless servers are a good idea (HTTP, NFS, SMTP); for this reason, most people are going with web services calls (XML-RPC or SOAP) and using HTTP pipelining to erase the TCP connection negotiation overhead. This solves 95% of the problems that BEEP is designed for.

If you're still convinced that you really, really, really need a stateful connection, XATP is much simpler and gets the job done just as well as BEEP.

[ Just imagine what this is going to do to the Playboy Channel and Spice TV.... ]

Well, those channels are already getting some targeted client-side pop-ups, triggered by scripted content.

-=Ivan

Practice safe browsing! Suppress pop-ups! Use Mozilla.

Never claimed it was Mozilla, and I'm not talking about the general file association. The Quicktime plug-in would get installed, and then handle .png within the browser. Even if you disabled it in the menu within the Quicktime plug-in, it would still try to handle it. You have to remove the plug-in from Mozilla's plug-in directory. I had no problem with Quicktime hadnling Quicktime movies in the browser, I just didn't want it to handle PNG. This Bug details quite a bit about it. Not the biggest issue in the world, but still a bit of a pain.

What's next, is TW going to use its power over architecture to mandate that its users connect to RR with Windows/Mac through Internet explorer, and not on alternate OS' such as Linux, BeOS, etc, nor through alternate browsers like Mozilla (which I'm using now)?

Time Warner Cable's parent is AOL Time Warner Inc (hereinafter "AOL(tw)"). AOL(tw) owns Netscape Communications Corp., which provides most of the labor and funding for The Mozilla Organization, the group responsible for the Mozilla browser technology used in the Netscape 6 browser and the forthcoming Netscape 7 browser. I don't see any AOL(tw) subsidiary blocking use of Mozilla in the foreseeable future.

It's very unlikely they could disable your "Save As" without disabling all of your web access. Could it just be that IE is retarded? Try another browser like Mozilla or Opera. You do have choices you know.

Did that 'nice hotels' link really have to be there? In a Slashdot story, we expect that one of the links will have part of the specific story in question. Instead, I read through an extremely vile description of a hotel in New York City. Is throughing in pointless links really necessar y?

This certainly approaches the status of 'non story'.

I've used Mozilla 1.0 as a mail client in a Fortune 500 company. It works juuuust fine. Calendaring functions aside, it's as good a mail client as Outlook, without the evil.

And if you're lucky enough to be on OS X, grab a copy of Mozilla 1.0a right away. The smoothed text is strikingly beautiful on a good monitor (I'm using Futura Book at work and it looks great).

For what it's worth, Mail.app is a fine mail client, but the original questioner is not planning on buying Macs.

I've used Mozilla 1.0 as a mail client in a Fortune 500 company. It works juuuust fine. Calendaring functions aside, it's as good a mail client as Outlook, without the evil.

And if you're lucky enough to be on OS X, grab a copy of Mozilla 1.0a right away. The smoothed text is strikingly beautiful on a good monitor (I'm using Futura Book at work and it looks great).

For what it's worth, Mail.app is a fine mail client, but the original questioner is not planning on buying Macs.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

ideally, the build will only break if two changes on the same night contradict each other

Another reason a change might break the build is if the software builds on multiple platforms. I think this is one reason Mozilla has dozens of computers continuously building it rather than one nightly build that may or may not compile the first time. This doesn't catch all checkins that make Mozilla unusable (we have a "smoketest" team that make sure each nightly works well enough to test it), but it does give everyone immediate feedback if a checkin stops the build from compiling or makes it fail some automatic tests.

Of course, it helps that compiling Mozilla takes less than an hour.

Mozilla still has some missing hackers as well.
Mainly... David Nebinger, 'Uncle George', Makoto Kato, and Thierry LeBouil.

Cached version of the Knuth document is here.

Time passes, Mozilla reaches 1.0 - and breaks the SVG plugin. Well, yeah, it may be Adobe's fault, but guess what this does to our already-in-progress site? Forces us to drop Mozilla support since the bug crashes Mozilla on our site. Really damned annoying, especially because the site used to work with Mozilla.

Anyway, a feature request gets added that means a floating panel that follows the scrolled viewport - something easily achevable with the onscroll event. Except guess what? Bug 35011 pops up - the code doesn't work in Mozilla. After spending an hour or so trying to figure out why I pop over to Mozilla and find Bug 35011.

And it may be marked FIXED, but check the "target milestone" listed - it's 1.0.1. Decidedly not 1.0 - I can guarentee you it does not work in Mozilla 1.0 - try the test case given for the bug. It will not work in Mozilla 1.0.

Since there is no way I can convince anyone that telling the users to use browsers marked as a "bleeding edge alpha release" - straight quote from mozilla.org, no trolling - I'm left with not bothering to test the site in Mozilla.

Were those two bugs fixed, I could get around to ensuring all the Javascript (which is required by the end-users) works in both browsers - until those bugs are fixed, I just kinda have to wait around and continue developing for IE and hope that when Mozilla 1.1-stable is released, the code won't be too IE-specific.

Until either Adobe or Mozilla addresses the SVG plugin, vast portions of the site will cause the browser to crash - or be unusable. We didn't want to use Flash and so went with the "open standard" and it turns out that by doing that we're locking people in with IE - now do you understand?

No trolling - just the simple facts. Due to those two bugs, the site is unusable with Mozilla - literally - because the only page that doesn't use SVG requires the onscroll event to work correctly, or things get ... weird. (It's dynamic in other ways, which means that the bar that should float on the top will occasionally get moved in Mozilla when certain events occur - meaning that Mozilla users wind up with a bar stuck in the middle of the data they wanted to read.)

So I would say that both those bugs are showstoppers for the project I'm working on. Yeah, the first bug might be "fixed" - but it isn't fixed in the stable release. The second bug might "not have anything to do with Mozilla" but it is something that used to work with Mozilla and now doesn't work with Mozilla. Meaning that Mozilla gets the blame, and the site is unusable with it. Until they get around to releasing the next "stable" version.

(And anyone who wants to argue that this is a troll might want to instead expend that energy doing something useful like bugging Adobe to release an SVG plugin that works with Mozilla, so that half the site works again.)

http://bugzilla.mozilla.org/show_bug.cgi?id=89853 is the Bugzilla note on this. I recommend "vote"ing for it, as it will add numbers to the Mozilla's teams pleas to Capital One et al to stop this kind of practice.

FWIW, I did propose an Ask Slashdot immediately after Mozilla 1.0 was along the lines of "Which bank should I switch to given Capital One doesn't support Mozilla", which would have been a great thing to send a link of to their support people. I suspect the editors were a little worried about all the complaints of how Mozilla was coming up in every news article though. I may propose such a thing again.

• National Australia Bank Click "Register Now" and you get a "Your Browser Version is not supported"
• CN Rail North America's Railroad (Excluding non-NS6 users).
• Bank Of America Try to apply for a gold card and the form gets screwed up.
• Benjamin Moore Sorry our page is designed for IE only, buy your paint elsewhere.
• Novartis Screwed up rendering.
• Connectsite Exchange, Collaborate, Connect! Unless of course your using a non IE browser, then go away.

This isn't counting the 1720 Tech Evangelism bugs that have already been resolved. Sites like salomonsmithbarney.com, yahoo.com, cbs.com, citrix.com and many many more have all resolved improper coding issues that screwed up non IE rendering. But the positive news is that in 1720 cases web administrators have changed their websites to make them unbroken.

Here's an example. One of the most highly reported bugs (bug 114812) that has since been fixed was with hotmail. Due to faulty javascript implementation if you would select the "ALL MESSAGES" box in your inbox only one message would actually be selected, so to delete the mountains of spam that accumulate daily you had to click the box beside _each_individual_message_. Clicking 200 checkboxes after not checking your mailbox for a few days does not a fun time make. Anyway after about 6 months of pestering microsoft finally fixed it. The moral: If complaining can make Microsoft make its pages standards compliant well the sky's the limit.

Anyway if you want to do something to help check out Mozilla Evangelism The site is chock full of advice about how to report and deal with non-compliant websites. You can even use the Letter Writing Tool to write and send a nifty letter to website administrators who haven't yet seen the light. Obviously the site is geared to getting things to work properly in Mozilla, but the fact is, things tend to work in Mozilla if they are standards compliant.

I actually don't mind a little loose html here and there. Small font types are more a problem for me than a table with a misaligned graphic. My biggest gripe, however, is when some webdesigners *program* into their page to redirect if not using IE. They won't put forth extra effort to create compatible websites, but they will go out of their way to prevent you from entering their site if you don't use a specific browser.

Incidentally, this is not a small problem. As documented by bugzilla, users can enter hotmail.com using IE or Netscape, but not Gecko (or lesser known browsers). while the impact is small now (99.x% of users on IE), as embedded devices crop up and more users try to customize their browsers, it becomes more and more a problem.

You may have a slow-ass computer, but there's simply no reason to continue using Netscape 4, no matter what you may say.

There are stripped-down versions of mozilla out there. You can use Opera or Internet Explorer 5, if you run Windows. You may even be able to stomach Mozilla or Netscape 6 if you've got a computer built this century.

The world does not owe you a favor for having a slow-ass computer, though. We're not about to sit idly by while your shitty 486 attempts to render our modern websites. Stop using NS4. Times are changing. Get with it, or give up. But, stop whining.

- A.P.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Now that Nav7 is on the way, I can drop nav4 support. IE 6 is out, so I can drop IE 4 support.

I already droped "support" for nav4 on the mozilla start page. I didn't fix the green text as it meant breaking the standards. It still displays, and is functional, but it sure isn't pretty.

All the DHTML sites I visit are using standards compliant code so it just seems to work. In alt.javascript I've noticed people mostly give responces which follow the DOM standards.

I have found a few corperate web sites which don't work with my web browser. ati.com (Now it works, but it didn't in the past), electronic arts (Site redesign fixed the problems) and the government of canada's (un)employment insurance web site (It has a warning for nav6 users but I never bothered to look into it). But those are the exception to the rule.

In general, I don't really see this as that big of a problem. Just asking the web designer to fix the web site usually works. And if you need help figuring it out, the w3c always has their Evangelism mailing-list and Bugzilla has tech evangelism bugs where they will notify the author of a particular web site sending them information on how they can make their web site work in w3c compliant web browsers.

All the DHTML sites I visit are using standards compliant code so it just seems to work. In alt.javascript I've noticed people mostly give responces which follow the DOM standards.

I have found a few corperate web sites which don't work with my web browser. ati.com (Now it works, but it didn't in the past), electronic arts (Site redesign fixed the problems) and the government of canada's (un)employment insurance web site (It has a warning for nav6 users but I never bothered to look into it). But those are the exception to the rule.

In general, I don't really see this as that big of a problem. Just asking the web designer to fix the web site usually works. And if you need help figuring it out, the w3c always has their Evangelism mailing-list and Bugzilla has tech evangelism bugs where they will notify the author of a particular web site sending them information on how they can make their web site work in w3c compliant web browsers.

Not when you're using a browser that doesn't come with flash...

Tabbed browsing - allows you to switch between pages without having to switch windows

I am not Chinese and do not speak Chinese, however I am working in China and was trying to introduce Linux. The following text treats Chinese == simplified, however most of the stuff should be valid for traditional too.

First of all, Chinese under Linux is hell. There seem to be no people being interested in developing open source in China. And if they do then it's difficult to find, crappy and unfinished. Just look at the Mozilla 1.0 simplified Chinese translation, it's not there, the guys did not move since 0.9.8. The Chinese HOWTO is quite old (1998!) and most of the links are dead and the information inside useless (practical experience).

You have several alternatives, I suggest you forget about them: RedFlag Linux (Experience based on 3.0, Redflag 3.2 beta ISO)
I had to use the text installation: I guess it was unicode without unicode support, so all I saw was messy characters but not Chinese. Somehow it's similar to redhat so I was able to click through. After the installation: whoops, the system is asking me for my registration key otherwise I can try RedFlag linux for 40 days (? do not remember how many exactly). It was not just a key, it was one of the Microsoft dimensions. After choosing the trial I ended up in Kde trying to look like windows. It had a tray, and a start bar, the Control Panel and so on. But I had a feeling it was there but it could not satisfy me, and I could not stand the little penguin patriotically holding that red flag up. The Chinese input seems to me to be the most advanced, but the system it self seemed to me unstable. Most modifications were in the interface and trying to lock down the system so you need to get that key after the trial period.

Office: RedOffice different company, same red. It's OpenOffice 1.0 looking like Office XP, that's all except there is no source code, no binaries, only a trial version and a price of 398RMB (~50US$) for the full version. Stick with Chinese OpenOffice.

Mandrake has in my opinion the best Chinese support. You only need to install it using the Chinese language. If you install it using English and then switch to Chinese you will have several problems, like you desktop disappearing etc. Do not use Unicode, use gb or big5 only, I was not able to see anything by switching to Unicode.

After the installation you should have a Chinese kde, Chinese Mozilla 0.9.8 and some more software in Chinese. The best input for simplified is Chinput, for Big5 Xcin and that's how Mandrake is doing it, if you use gb you will get Chinput by pressing Ctrl+Space and Xcin on a Big5 system.

Turbolinux seems to have taken over the Chinput project, therefore you will find no info on the net. They made an extension to Chinput called ZWinPro (ZWinPro-3.2-11.i586.rpm) you need to forceinstall it (solve some libary deps, install unicon but do not uninstall Chinput) and forceinstall Mandrakes Chinput again. This will give you Mandrakes Chinput with a configuration toolbar and some binaries which allow you to use Chinese input for all applications. There are some minor probs you will need to fix (font alias missing, etc), if you have trouble contact me.

The only problem about Chinput (and probably Xcin) is: it's dumb, the windows input tries to guess what you are typing. Means, you need to write character by character on Linux, does not matter if you use Pinyin or Woubi (or what ever you call it). This is very unconvenient and a killer for every Chinese linux desktop. Nobody will want to type 10 min on Linux when he can be finished in 2 on windows.

Next get the Chinese version of OpenOffice1.0 and English Mozilla 1.0. If you want to use a Chinese browser stick to konqueror, Mozilla 0.9.8 is not stable and crashes randomly.

You will want to get some Chinese ttf fonts from windows, as the fonts on Mandrake are quite ugly.

paul

Ummm... what about Transformiix? That would be the Mozilla XSLT engine, which is built right into Moz 1.0. Check out the project website here.

I had no idea there were people on /. that still used browsers that supported popups. Here's a hint, head over here.

Right now GUI wise, it's the easiest and nicest way to use gnupg for emails in Windows.

PZ should get involved with Mozilla. For literally years I've been waiting for someone to build in some sort of public-key email (and newsgroup) crypto. It's still not there yet, and THAT has prevented several people I know - including myself - from adopting Mozilla as my sole internet access tool. I'd love to be able to dump some of the crap I run for email and usenet.

First it was the export restrictions that were deterring Mozilla crypto. Now it's something else. I guess these projects qualify for some of what's being done today, but I needed Mozilla to do built-in crypto years ago. The standard Mozilla comeback is "do it yourself". Well, I have neither the time nor the skill to do that. But Phil does!

Are there currently any applications that will sync Mozilla mail, address books and calendar events with PalmOS based handhelds? If not, are there any plans in the works for this to become a reality?

I found some stuff in the Mozilla Status Updates that may interest you:

• May 31st MailNews Update
• • Started looking into the requirements for Palm Pilot sync
  • ...
  • Started investigating the requirements for implementing an Mozilla-Palm Address Book synchronization module.
  • looked into the details of Address Book APIs in MAPI for IPC interaction with Mozilla Address Book.
  • looked into the requirements for implementing HotSync process of Palm used to synchronize data between a Palm application and the corresponding desktop application.
  • looked into the Netscape 4x implementation of Communicator AB Palm synchronization
• Started writing the analysis and requirements document for Mozilla/Netscape Address Book HotSync.

June 14th MailNews Update

• Looked into the details of Palm Conduit Framework
• Looked into the details of the 4x conduit code
• Continued working on the Palm-Mozilla AB sync detail design
• Started working on a simple prototype with a basic conduit and a call into Mozilla AB to open an AB Mork DB in the Mozilla process space from the conduit in the Palm HotSync Manager process space.

The comments in the reports were written by Netscape employees. It looks like Palm sync functionality is in the early planning stages, so Netscape probably want it for Buffy, the codename for their next release after 7.0 (7.0 is codenamed MachV). Basically, it looks like it's in development but it probably won't be available in Mozilla for some time.

Are there currently any applications that will sync Mozilla mail, address books and calendar events with PalmOS based handhelds? If not, are there any plans in the works for this to become a reality?

I found some stuff in the Mozilla Status Updates that may interest you:

• May 31st MailNews Update
• • Started looking into the requirements for Palm Pilot sync
  • ...
  • Started investigating the requirements for implementing an Mozilla-Palm Address Book synchronization module.
  • looked into the details of Address Book APIs in MAPI for IPC interaction with Mozilla Address Book.
  • looked into the requirements for implementing HotSync process of Palm used to synchronize data between a Palm application and the corresponding desktop application.
  • looked into the Netscape 4x implementation of Communicator AB Palm synchronization
• Started writing the analysis and requirements document for Mozilla/Netscape Address Book HotSync.

June 14th MailNews Update

• Looked into the details of Palm Conduit Framework
• Looked into the details of the 4x conduit code
• Continued working on the Palm-Mozilla AB sync detail design
• Started working on a simple prototype with a basic conduit and a call into Mozilla AB to open an AB Mork DB in the Mozilla process space from the conduit in the Palm HotSync Manager process space.

The comments in the reports were written by Netscape employees. It looks like Palm sync functionality is in the early planning stages, so Netscape probably want it for Buffy, the codename for their next release after 7.0 (7.0 is codenamed MachV). Basically, it looks like it's in development but it probably won't be available in Mozilla for some time.

Are there currently any applications that will sync Mozilla mail, address books and calendar events with PalmOS based handhelds? If not, are there any plans in the works for this to become a reality?

I found some stuff in the Mozilla Status Updates that may interest you:

• May 31st MailNews Update
• • Started looking into the requirements for Palm Pilot sync
  • ...
  • Started investigating the requirements for implementing an Mozilla-Palm Address Book synchronization module.
  • looked into the details of Address Book APIs in MAPI for IPC interaction with Mozilla Address Book.
  • looked into the requirements for implementing HotSync process of Palm used to synchronize data between a Palm application and the corresponding desktop application.
  • looked into the Netscape 4x implementation of Communicator AB Palm synchronization
• Started writing the analysis and requirements document for Mozilla/Netscape Address Book HotSync.

June 14th MailNews Update

• Looked into the details of Palm Conduit Framework
• Looked into the details of the 4x conduit code
• Continued working on the Palm-Mozilla AB sync detail design
• Started working on a simple prototype with a basic conduit and a call into Mozilla AB to open an AB Mork DB in the Mozilla process space from the conduit in the Palm HotSync Manager process space.

The comments in the reports were written by Netscape employees. It looks like Palm sync functionality is in the early planning stages, so Netscape probably want it for Buffy, the codename for their next release after 7.0 (7.0 is codenamed MachV). Basically, it looks like it's in development but it probably won't be available in Mozilla for some time.

Having a thousand 10 line files does nothing to improve maintainability.

My obligatory plug for The Mozilla Project. Not quite one function per source file, but definitely lots of very small source files, each implementing a very narrow slice of functionality. Mozilla is pretty well factored code, and maintainability is enhanced by the separation of responsibilities. It makes it possible to enhance or fix problems in one area, say the in nsFTPChannel, and know that all the thousands of other lines in the program will be largely insulated from those changes.

Yes, it does take a while to get familiar with the entire Mozilla codebase. The flip side is that you only have to look at and understand a small fraction of it to start becoming productive.

If you are using C++, Large Scale C++ Software Design is definitely a recommendation I can second.

yes and some more alpha code
http://www.mozilla.org/mailnews/arch/ABSyncClientD esign.html

but the real deal is
SyncML that works on phones and soon palms that is a nice stable platform for doing this the only problem would be patents but since they dont have any filed in taiwan it does not really matter

http://sync4j.sourceforge.net/ is a big list

regards

john jones

In any case, there are still some reasons why OSS modules don't fit well with FIPS 140.

• First, someone needs to go through and verify that the module is, in fact, compliant to the FIPS 140-2 standard. In order to do that, you'll need to at least read through (and understand) the FIPS 140-2 standard, and the Derived Test Requirements. Depending on what algorithms the module implements, you'll also need to read through a few other algorithm standard documents, some of which are available for free through NIST, and some of which are ANSI X9 documents, which will cost you $80-$150 each. These documents are all boring. Really boring.
• FIPS 140 requires a fair bit of module specific documentation. How many people do you know who have a ripping good time producing Configuration Management policy and procedure documents? None? I certainly don't, and I do this sort of thing for a living. How about expressing the module's design in an FSM? OK, that's not so bad, but now annotate the source code with references to the FSM. Ick. Don't forget a nice Key Management document, and the Security Policy for the module. It's all enough fun to choke a horse.
• Someone needs to pay the testing laboratory. These evaluations aren't cheap, owing to the fact that the lab has to spend a bunch of time reviewing the product, writing the report (which ends up being more than 100 pages in all) and dealing with NIST and CSE. Even if the OSS group has their shit together, it's still going to cost at least $15k in lab fees. Probably more like $20k-$30k. In addition, NIST keeps threatening to charge to review the lab report. The proposed fees vary from "nominal" (a few thousand dollars) to "ridiculous" (nearly as much as the lab charges for the testing in the first place). So, who's going to pay? The developers? I don't know about you, but I'm not quite that committed to any of the OSS projects I'm involved with.
• Even once you get the FIPS 140 cert, it only applies to the particular version that was tested. So, if you change anything at all, you need to send the changes back to the testing laboratory for their review. Assuming that nothing much changed, they'll only charge you a few thousand to write a note to NIST asking them to update their website. If any of the changes were security relevant or (god forbid) effects the security policy or FSM, you'll need to cough up another $10k-15k to do a recertification based on the previous report.

Boy, that sounds fun, don't it? Even if you overcome the central issue of documentation, you still need a shit load of money to push it through. The entire process just isn't set up for independent groups to get certified.

All that being said, I note (by looking at the pre-validation listthat Sun is near the end of the process for certifying the NSS, which is a portion of Mozilla...

If you use Mozilla, make sure to install Bannerblind.

As the name suggests, it hides any banners on a website you're viewing. It works by telling Mozilla to not display/remove images of a certain size (most ads are of a specific size). You can also add different banner sizes as time goes by (I've eliminated 99% of ads - Slashdot is completely ad free for me).

http://bugzilla.mozilla.org/show_bug.cgi?id=35011

Quote from the bug:

I'm glad to see that this bug hasn't been left to the wayside. If there is any
chance that this will not be finished for 1.0 I'm willing to sponsor it, if that
helps. I don't have much money but could probably sponsor the bug for about $500
USD, if that is what it takes to get it finished for 1.0

And several more developers claiming that they have been (privately, in email) offered money to fix that bug.

Is this a new way to make money in the open source realm or what?

The computer will now know everything about you -- who you talk to, where you go, how you work. And all of this will be owned by Microsoft.

they won't know about me.

Well I am comparing my "IE in windows" to "mozilla in linux". IE supports the HTTP standard better, it doesn't die as often [assuming you have a clean install of windows... something not so easy] and generally just is easier to use.

What HTTP-standard is that? The "Real" HTTP-standard set up by W3C or Microsofts HTTP-standard?

Obviously mileage vary when it comes to Mozilla, because I haven't had it crash on me once in Windows. Never. It happened once in IRIX, something I reported to bugzilla and that bug was gone 1 month later.

I find even Mozilla 1.0 will die on a page or two [mostly at yahoo] and just hang without anything. In windows with IE I never really had any problems.

Can you give some examples of pages where mozilla dies? Does it happen everytime you visit those pages? Have you reported this to the mozilla-team via bugzilla?

And trust me when I say IE supports HTTP cleaner. I'm in the midsts of writing a web server and in due course I have tested it against wget, opera, mozilla, voyager, konquerer and IE. IE handles pretty much all of the HTTP specs [that my limited server uses just fine]. IE will also properly handle invalid replies [e.g. with no Content-length].

I believe you. In mozilla you have to write proper http/html for it to work, not Microsofts bastardization of it. Yes, the redmond based company has embraced and extended this protocol too. I would very much like to know how Mozilla handles the invalid replies that you spoke of.
Yes, IE is much more forgiving than Mozilla. This is not a good thing. That encourages webmasters to write bad code. If you should complain about something it should be about the persons who write bad html that don't comply to the w3c standard.

Mozilla works somewhat decently but I find it won't handle all cases of GZIP messages [I actually submitted a bug w.r.t this].

I agree. Mozilla is a good product, it isn't perfect. It isn't "done". It's a good product in the making.
It's good that you filed a bug-report. That is actually very constructive, and a lot of people could find this useful. Thank you.

I use Mozilla because it's a standard compliant cross platform browser with lots of features that IE misses still. I'm sure they'll catch up, but until they do Mozilla is my browser of choice.

Best regards

.haeger

The Google toolbar is one of the coolest things about IE (maybe the only one <grin/>). However, you need a Windows system with IE in order to install and use it. Are there plans to have to toolbar available for Mozilla, and non-Microsoft systems in general?

Just a warning, if you do want to use UFS there is a bug in the mozilla code base that will prevent mozilla and netscape 6 from running on a UFS partition. Also various apps have little problems i have run into, for instance the quicken installer doesnt work, but the app does. Chimera and omniweb work tho, so at least you wouldnt be stuck with ie!

Well, get the source and do it yourself :)

Actually, this is something I've been meaning to do, I'm in the same boat as you, and yep, it's annoying ... Just ain't enough time in the day!

At this stage, it is impossible to design a page that:

1. Uses a complex CSS-based layout (though simple ones work pretty well)
2. Renders correctly in IE5, IE6, and Mozilla
3. Adheres strictly to the standards (XHTML 1.1, CSS2)
4. Doesn't use any browser detection tricks

It's not possible to comply with all of 1, 2 and 3 because IE5 doesn't follow CSS box model. For example in IE5 width=padding+contentwidth+border but in real CSS width=contentwidth. In addition, not a single version of IE correctly support CSS2 box model. As for 4, if I write html>body h1 {color: red;} does that count as browser detection trick? It's proper CSS2 but no version of IE supports it so it can be used to hide CSS properties that are known to be broken in IE like position: fixed.

Issues like Mozilla's poor/non-existant support for Q-element or lang() selectors look pretty minor compared to IE's bugs.

I make pages according to spec, test with mozilla and hide the CSS that breaks IE or Opera with selector tricks. It seems that Opera is the thoughest one to work around because it implements so much that simple selector trick is hard to come up with but some of it's bugs are so bad that they cannot be left as is. (position: absolute compibined with bottom property comes to mind first.)