Slashdot Mirror

When you start typing in the URL bar, wouldn't it be handy if the result-list was sorted by most-frequently-accessed, or most-recently-accessed? Well, that has been proposed (bug 78270).

However, it's also marked Priority P4 and Future :(. But, you can vote for the bug to show your support (of course, you'll need a free Bugzilla account to vote).

When you start typing in the URL bar, wouldn't it be handy if the result-list was sorted by most-frequently-accessed, or most-recently-accessed? Well, that has been proposed (bug 78270).

However, it's also marked Priority P4 and Future :(. But, you can vote for the bug to show your support (of course, you'll need a free Bugzilla account to vote).

When you start typing in the URL bar, wouldn't it be handy if the result-list was sorted by most-frequently-accessed, or most-recently-accessed? Well, that has been proposed (bug 78270).

However, it's also marked Priority P4 and Future :(. But, you can vote for the bug to show your support (of course, you'll need a free Bugzilla account to vote).

Unfortunately, there are still 133 bugs targeted for 0.9.9 still open. One of these is mine, and I am not happy that it's still open, but that's the way things go. People demand a new release.

Alas, there are 891 bugs targeted for 1.0, plus the 133 0.9.9, plus bugs that are yet to be reported that need to be fixed for 1.0. Now, I am starting to sound like that MozillaQuest retard, but I really doubt that even 1/4 of these will get fixed before 1.0.

According to the road map, Mozilla 1.0 will be out March 27th. Only 16 more days. Of course, according to the roadmap, 0.9.9 was supposed to be out a month ago.

a href="http://mozilla.org/roadmap/branching-15-Feb- 2002.png"

No.

Even worse, adding support is going to be a bitch because, to quote from the Mozilla MathML Project page

Mozilla does not yet support the mixture of XML and HTML within the same document. Thus a fragment inside a HTML document is not rendered in Mozilla. [1]

In other words, the doc (and therefore the whole site, practically speaking) has to be in XML/XHTML to be able to use MathML with Mozilla. We've seen time and time again that Slashdot (and to a lesser extent K5) is not even really HTML compliant, what are the chances of meeting the higher standards of XML validity?

Slim to none.

So thanks for the attempt, but until the slow among us start being good netizens then it is too little, too late.

[1]Yeah, I know it says "not yet" but

1. This is 0.9.9. If it isn't there now, when will it be?
2. I can't find a reference to this issue in Bugzilla

The release after 0.9.9 will be 1.0, but it's possible that 1.1 alpha will be released before 1.0. If that happens, I'd expect to see a "1.0 beta" or "1.0 release candidate" before 1.1 alpha. (See the Mozilla Development Roadmap for more.)

Mozilla Roadmap

A good example is Mozilla 0.9.9, which was just released today and already incorporates the fix.

What's the right approach to make sure the web sites change rather than the AOL customer base?

There is something you can do to help make major sites more compliant with web standards. Report them as Tech Evangelism bugs in Mozilla's bug tracking system. Then Mozilla engineers can assist in making the site adhere to the standards.

Basically, many webmasters are ignorant, or even arrogant enough to ignore standards compliance. Those who fail to see that standards compliance is the way forward, will have painted themselves into a corner. The cost of completely re-doing a site which has been carefully written specifically for IE and all its non-standard extensions and quirks, could potentially lead to more dot.com deaths. This is a good thing! People who don't care enough to inform themselves don't deserve to do business. Am I being harsh? Perhaps, but being an avid user of alternative browsers, I am tired of fighting with arrogant web designers who don't understand what they are doing.

Finally, we will see who has the foresight or the insight to survive this.

Grim predictions aside (I may have been a bit negative above), this naturally benefits users of alternative browsers. Mozilla and Opera will both be able to display more pages than before, and their user base will probably grow rapidly because of this. After all, the feature sets of these browsers are far superior to IE from a user's point of view (disclaimer: This is a personal opinion based on my personal preference. Ok? Please, no browser wars).

Note that I am not even bashing IE here. The good news is that this can be cheaper for online companies in the long run, since it will pay off to write standards compliant code, rather than writing specifically for only certain browsers. MSIE 6 has decent standards compliance. The problem is the proprietary extensions used so extensively instead of the W3C counterparts.

This becomes even more important now that handheld devices are becoming more and more popular. We will see a significant increase in the number of devices used by consumers, and these devices will be using alternative browsers as well.

It basically boils down to this: The browser market is diversifying, and if AOL decides to go with Gecko, this will speed up this process. It will not be a nice transition. Many may find that they have major problems due to "IE-centric" code on their sites.

AOL may not be doing this because they desperately want to get rid of IE or because they want to support alternative browsers (who knows, there may be many reasons, perhaps these play in as well). Nevertheless, for once, it would seem that the consumer - the user - benefits from such a drastic move.

If AOL are indeed planning to move from MSIE to Gecko, that is...

Last I saw, Mozilla was up to release 0.9.8, at least according to the project website. Hopefully you are right, though. IE is a piece of bloatware. I've got Netscape 6.2 running on my windoze box at this time. My next step is to start using the penguin.

That has been fixed. Since Mozilla 0.9.6, What's Related data is only sent if the sidebar is enabled and the What's Related panel is active. See Bugzilla bug 53239.

I think your *customers* would have more of a problem with what you described than Microsoft would.

I did call it an 'unlikely' scenario. And what you say is true for your average L^hUser. But Rotor doesn't include the kinds of things I would need for applications a non-technical user would care about, like Windows Forms. OTOH applications which could run on Rotor without problems include Server-Side stuff and utilities. In that case someone who really wants to run it on something other than Windoze will have both the skills and the incentive.

Besides, I write business applications, not word processors. I am leaning towards Mozilla as the UI platform of choice for my future applications. But I do want to write the hard parts (business rules, data management and heavy processing) in something other than XUL/Javascript, and where I can break out those objects and run them on different boxen. I have done a lot of comparing between Java and C#, and gotta say that C# is the best choice for me - if it can be cross-platform enough and if there are open implementations. Between Rotor and Mono (and there is one other I think) it might be getting there.

Jack William Bell

Second what is the deal (and yes, I clearly have the source) with Mozilla's textarea entry widget? This thing is a nightmare to use. Don't even pretend to try to cut-and-paste into this thing if you want to produce readable results.

There were some issues with textwindows adressed for 9.9 (which is due soon), i hope this behaviour was adressed too (sounds likely, since it is apparently a problem of cursor positioning ... we'll see). The problem occurs, when you place the mousecursor somewhere where no text is. Since in most cases people try to paste to an empty space this will happen almost always. Instead of inserting the text before the previous linebreak mozilla will place it somewhere in the window. The workaround is, to paste where text is (maybe type a few spaces and paste between them). Hopefully this information is obsolete in a few days.
--

They stopped for a minute and came to the conclusion that it's alright to give less than godlike praise to a product that's not GPLed.

opera mozilla

It's better than Netscape 6 (more up to date rendering engine and surrisingly stable considering it's still in beta) and there's no chance of any nasty behaviour on the behalf of the developers thanks to its open source nature.

Why not try using Mozilla instead of IE?
No page-widening with that...

• Myth: KDE is more integrated than GNOME
  
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac.

• Myth: KDE is easier to use
  
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. What about application (see GNOME apps later) installation and removal: GNOME has the excellent RedCarpet by Ximian , which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase... which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post on a zealot-ridden site can reduce the result to a running joke. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system - and indeed, can co-exist except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead. Both Hewlett- Packard and Sun Microsystems have committed to using GNOME as the desktop for their Unix systems. This ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME effort is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror is a fine piece of software - it's authors deserve plently of praise - it is, however, quite unreliable and lax in its support of basic web standards compared to either Mozilla or Opera . It is also extremely slow - slower than the latest incarnations of the GNOME Nautilus filemanager/browser.

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  
  Reality: See also: Qt/TrollTech. Easily the most common wail heard by KDE developers - and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt . KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2. GNOME applications wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet ,X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade , Anjuta . All of these packages ooze quality, far outclass and are, at least, 18 months ahead of their KDE/Qt counterparts. It's not only in the area of user applications that GNOME is lightyears ahead, with the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo ), media (Gstreamer ), internationalisation (pango ). As a developement platform, GNOME 2.x is, frankly, years ahead of KDE. And what's more, it is not tied to a lowest common denominator cross-platform bloat-fest like Qt. Yet despite all this, we are still fed the lie that Qt and C++ makes development easier. Judge for yourself.

• Myth: KDE is faster and/or takes less memory than GNOME
  
  Reality: KDE is written in C++. While this is not necessarily a bad thing, it is when the programmers do not know enough to avoid certain pitfalls that can plague software projects. Stupid use of ++/-- with C++ objects; masses of unnecessary allocations and deallocations of memory, and the most cretinous of all, blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the KDE architecture and basic design.

• Myth: GNOME development is slower. KDE releases faster.
  
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the consequent problems with libraries. It bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version. Occasional releases of the entire GNOME system are done, and that's when the GNOME version number is bumped (currently it is 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  
  Reality: Qt started out as non-Free. KDE developers knew this violated the GPL and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Labyrinthine licensing nightmare.

• Myth: Most good GNOME apps are actually GTK applications.
  
  Reality: Most KDE apps, such as those from The Kompany are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

• Myth: KDE is attractive/GNOME/GTK is ugly
  
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

That's just begging for someone to write a wrapper for Gecko and drop it in place of shdocvw.dll and/or mshtml.dll.

Problem: Bug 74201 (implement IE DOM extensions) is VERIFIED WONTFIX. Apps that expect mshtml.dll expect the document.all JS API to be available. The Mozilla Organization is strongly opposed to implementing document.all.

And i'm tired of people conmplaining about Flash [...]

Does it mean, that you think that I should keep my mouth shut, and do not complain, because you are tired hearing about a problem of mine?

Does it work for you? Fine! Please, do not think, that all the others are idiots, or lamers.

Do you need to use forwarded X? My company would. Try X-forwarded flash, and if it doesn't work :-)), then read this (bugzilla.mozilla.org). And count the "idiots", who has this problem. Like me.

Try to use a gcc-3 environment. Wont work? No problem...

Use Solaris! Not works? Then read this bugzilla thread.

Works for you? OK! Those, for whom is a pain in the ass, they're just complainig!

And i'm tired of people conmplaining about Flash [...]

Does it mean, that you think that I should keep my mouth shut, and do not complain, because you are tired hearing about a problem of mine?

Does it work for you? Fine! Please, do not think, that all the others are idiots, or lamers.

Do you need to use forwarded X? My company would. Try X-forwarded flash, and if it doesn't work :-)), then read this (bugzilla.mozilla.org). And count the "idiots", who has this problem. Like me.

Try to use a gcc-3 environment. Wont work? No problem...

Use Solaris! Not works? Then read this bugzilla thread.

Works for you? OK! Those, for whom is a pain in the ass, they're just complainig!

There's actually a yet more useful bug request out there to get flash blocking on a per site basis, just like there's image blocking on a per site basis.
Work on it seems to have halted for a while though, but maybe that's cause it's really more a specific instance of the general case of being able to block any multimedia content from any site.

I just hope this'll be picked up soon, since the flash banners have gotten really bad nowadays.

They do make a Flash plugin for Linux (I'm using it on Mozilla right now)...

Flash for Linux v5.0r47

Now if its Macromedia's Shockwave that you are referring to, then yes, it is not currently available on Linux. I gasp at even thinking about people trying to do web sites ENTIRELY in Shockwave...

The SVG format does everything Flash does and more. Adobe SVG Viewer and Illustrator, JASC Webdraw have moved to support it and Mozilla already displays it. And because it's XML, browsers that can't display it won't croak when trying to display the propriety format. AND it can be dynamically updated in web servers such as Apache w/ Perl.

Vector graphics are good. It's clear that Macromedia is attempting to secure a monopoly here.

The prettier Core Graphics font antialiasing is available to Carbon apps (see here for an example), it's just harder to implement from Carbon apps. I wouldn't call this an OS flaw, it's just a place where the Carbon devkit needs some work.

Raise or lower windows; What is this? I really can't imagine that it is what it says, 'cause I don't see any purpose. Anyway - as with the previous point - I appreciate your effort in helping me, but I would rather do this myself. This time and forever.

It corresponds to the javascript function window.focus(). On Windows 98, that brings a window to the front, makes its titlebar blue, and directs keyboard commands to that window.

Window.focus() used almost exclusively in two situations:
1. Immediately after opening a window, focus the old window (only pop-under ads).
2. Immediately after opening a window, focus the new window (pop-up ads and useful windows). I don't know why sites do this, since it seems unnecessary, but many do.

If you've disabled "open unrequested windows", I recommend that you enable "raise and lower windows" so sites using #2 legitimately don't encounter a javascript error when they try to focus the window they just opened.

Once bug 117707 is fixed, window.focus() will do nothing instead of halting javascript execution when you have it disabled.

For some reason that setting broke an applicaiton I was working on that uses "requested" (onClick) popup windows.

That sounds like a Mozilla bug. Please file a bug and include a small bit of code that demonstrates the problem. Also, I'd appreciate it if you would reply to this comment with the bug number.

I understand Mozilla has had this feature for a long time. It is not a menu/GUI driven option, though.

You can edit the file user.js using the instructions in Custumizing Mozilla

Not exactly user friendly, but fairly easy anyway.

However, slashdot should be forthright about how the page views will be accounted. Is it a simple HTML page load, or something more complicated? What about requests for RDF? HEAD requests? Requests without images? Are there any other special cases? Also, slashdot should give non-subscribers a way to count their page views, so they can tell how expensive a subscription would be, based on their viewing habits.

Finally--every slashdot reader who subscribes should learn their browser's caching behavior--and maybe swith browsers! Does your back button reload slashdot (watching the "generated by a team of purple midgets" text is a quick way to check)? If so, you'll probably be throwing away your (half-) pennies on worthless reloads (unless you use such kluges as tabs and new windows).

Non-ancient mozillas prior to 0.9.8 would reload (as a result of bug 112564). I think (secondhand information) that IE does and Opera doesn't.

the link: http://www.marine-monsters.com/front/products/digi q.html

There are some large OSS projects that actively encourage feedback and bugfixes and so on. Even contributing small bits to them or minor bug fixes would show some experience in being able to deal with isolated portions of enormous programs.

Go get Mozilla. With it you can disable popups during page load and unload, but keep it going for onclick() and other JS events.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

(0.9.8 has all sort of Javascript options; can you say "goodbye popups"?)

- Sam

...or just use the latest build of Mozilla.
No page widening under that.

No, but you can use Mozilla.

Guidescope is a great, free (beer) service that allows you to get rid of advertisements. It has some problems -- it gets rid of any image with the word 'banner' or 'advertisement' (possibly even 'ad' but I'm not sure) in it -- but 98.62973% of the time it hits the ads and leaves everything else intact. You download a small program (Linux and Mac users, you may be SOL with this one) that acts as a local proxy running on port 8000. Tell Mozilla (if you use anything else, you're an idiot *flame,flame*) to route through it and ta'da! No more ads. It can also kill cookies. From what the press says, it interacts with a central database to check whether or not something should be classified as an 'ad', but while I haven't checked to see what it converses with, I don't think it really does. You can however block specific images, which is kinda nifty.

I've said nifty twice in this post, which is a bad thing, so I'm going to stop talking at the end of this sentence. (period.)

You have to go after your less computer savy friends and help them turn them off. Think of it in terms of who browses the web the most, and focus on the heavy users first, so that you eliminate the most potential page views possible.

This is the best place to go to configure mozilla not to do pop-ups. I would just cut and paste all the examples into prefs.js, and then remove them if you discover that one particular site you like abosultely has to have some javascript feature or another.

The war on pop-ups is best fought not by writing letters to corporations and webmasters and begging them for mercy; rather, cut off their food supply and let them find their own way. Think of all your less computer savy friends and family as the slow, dumb buffalo the Indians feed off of; remove the buffalo, the Indians get a lot more manageable. It's not the kindest analogy, but if you want to fight a war, pick your strategies from those that win.

I haven't seen a popup ad since I switched.

Blizzard just needs to release a legitimate version of the B.Net server

This is a great idea. A couple problems though:

1. The current battle.net server is an in-house application, which means (since they probably didn't develop it with a public release in mind), it's probably (a) really warty (not that this would matter to the average buyer) and (b) probably horribly coupled to all kinds of internal proprietary servers. I mean, look at Bugzilla; it's successfully used by a lot of projects, but it started as an in-house bug tracking system and *it still really shows.* Just try to set it up sometime!

2. The server would probably only run on Windows, since that seems to be the main audience Blizzard develops for. Or, alternately, if it runs on *nix, their marketing types would probably say, "well, our customers aren't running *nix, so there's no point selling it." Catch-22 here.

   Also, with LAN parties combined with Microsoft's infamous "no more than 10 people may connect to a Win2K Pro machine over TCP/IP" (yieh! you're just a *consumer*, a *nobody*, so sit down biotch!), Blizzard's lawyers might warn them about people violating Microsoft's EULA. And heavens, that might be worse than Software Piracy!

3. With the server released, that would be more code crackers could look at to try to reverse-engineer the CD key algorithm. True, this can be done with the game too, but maybe the authentication is written in perl or some other text based language that would be trivial to reverse engineer.

4. Blizzard/*Vivendi*. How likely is Vivendi to do anything that even resembles giving customers freedom? They're all about control of "consumers," nowadays.

5. Blizzard tech support, like any large tech support organization, is already overworked from idiots emailing them about trivial problems. At least they probably have a good procedure in place for dealing with this though. Server software is a completely different ballgame, and they'd probably have to hire new staff just to deal with it. To their minds, this could be just more money down the tube.

So basically I agree with you, but with the analysis for blizzard = spending more $$ on development + spending more $$ on tech support + fear of "software pirates" + general belligerence, I doubt it will ever happen. Oh well, we can always hope, right? :-)

I really would think by now that there would be a way to fix this behavior. Anyone got any suggestions?

Yes. Use a Real Browser, not a toy.

What would be great here is a mixing of those ideas and evolutions vFolder concept to push open-source far ahead of any commercial web and email programs I know of. -MS2k

I'd agree that XML is a good basis, but "XML" really doesn't provide much by itself. It's just a file format that is human readable. If you just use XML with a bunch of proprietary tags, your own XML language so to speak, you really don't gain much over the existing different syntax config files.

An automated tool has no clue what your ipaddress (or whatever) tag means at all. You need to provide additional context for tools to understand the semantics of the configuration data. To make configuration files understandable in a more intelligent sense, you need to either restrict the tags you use to your own configuration language, or you need to provide metadata of some sort.

Why is this intelligence necessary? Well there are all sorts of dependencies and relationships in configuration files. You might want a GUI to let you know if you change something that may break another setting, and so on. Plus ideally you would only allow legal values to be set. Data typing could be done with W3C XML Schema Definition Language, or RELAX NG schemas.

Which brings me to RDF, which I think would be better suited to this task than XML alone. If you use RDF (see http://www.w3.org/RDF/ ) you make it much easier to have a self-describing format that tools can do more intelligent things with than raw XML. While I don't think RDF, DAML+OIL, et al is enough to create a Semantic Web as Tim Berners-Lee is hoping, it _is_ a step in a higher-level direction that will support more intelligence in processing data.

Mozilla already uses RDF for various configuration files and I'm sure there are other applications that do too. Mozilla has a whole bunch of stuff about their RDF here.

XML is just a tree of "stuff" in human-readable format. RDF lets you set up properties and relationships in the data in a standardized way. I don't have a brilliant example to prove this to skeptics, but really it is a better way to represent a lot of types of data you want to be able to query. There are many knowledge bases, expert systems and other query engines already out there using RDF and even higher-level languages like DAML+OIL.

-Kevin

It's not that Mozilla's JS sucks, it's sites are using stupid browser detection mechanisms to distinguish between NS4 and M$IE, and Mozilla sometimes falls between the seats, and gets denied.

Whenever you find such a site, check bugzilla for it, and if it's not listed, report it for Tech Evangelsim.

Perhaps you should file a bug to remove tabbed MDI browsing (MS's current GUI recommendations agree with you)

Someone else already filed it, and I voted for it after it got wontfixed.

instead of letting your opinions on the matter color the issues of getting tabbed browsing to the 100% level

It's not "I don't use tabs", it's "I think tabs shouldn't be there because I think they're bad UI". Why should I fight for "getting tabbed browsing to the 100% level" if a) I think tabbed browsing should be removed as soon as new windows open quickly and b) doing so would interfere with normal keyboard navigation?

I'm talking about bug 40867.

Ben Bucksch of Beonex fame has offered to work on the roaming profile support on a tips-for-code basis. See bug 17048 for the background, and bug 124026 for the funding issues.

Looks very promising -- if you want this feature, consider throwing in a few dollars. If this kind of development model turns out to work well, it could be a revolution for large Open Source / Free Software projects.