Ramdom thoughts on the 2011 (and beyond?) Firefox release schedule
As I sit here at Panera Bread, catching up on some tech news, an article caught my eye concerning Mozilla's new approach to updates and, tangentially, the (revised) 2011 Firefox release schedule. This started my own wheels turning, as this has been a bit of an annoyance for me, so I thought I'd just jot down a few ideas...
Concerning Firefox's 2011 release schedule:
Why?
We (I say "we" because I do/have contribute(d) from time to time) have some bugs in Bugzilla which date back several years (some to the Netscape Communicator days, inherited by the Mozilla project - no kidding!). These have yet to be quashed, and all the while new "releases" just keep coming down the pike, bringing with them their own share of new insectoids. Wouldn't it make more sense to stay at a reasonable "release" level, and just fix it before adding new features (and after all, isn't the purpose of a new "release" to introduce new features)? We already have a mechanism in place for extending the functionality of the browser through plugins and extensions, anyway, so what's the point? (If Mozilla wants to emulate Redmond, then they should consider that under the hood, Windows 7 is NT 6.1, anyway, and Microsoft got a head start with NT growing out of OS/2 - NT started at version 3.)
Updating Firefox on Linux: the Dreaded “Couldn’t load XPCOM”
I bumped into this annoyance while updating my openSUSE 11.4 workstation tonight.
There are numerous mentions of this issue on the net, and numerous suggestions for addressing it. However, none of them (which I saw) really hits on the underlying problem, which is that somewhere, somehow, XPCOM can't start.
To understand what's going on, it's important to have a basic understanding of what XPCOM is, and how it is involved with Mozilla apps. XPCOM is an acronym for "Cross Platform Component Object Model," which is Mozilla's equivalent technology to CORBA or Microsoft's COM. Like any other "object model," XPCOM's function is to provide a modular framework vs a monolithic one. This modularization allows XPCOM to be (mostly) platform-neutral, making it possible to run the Gecko rendering engine on a variety of platforms. So, as the Gecko engine is composed of XPCOM components, if XPCOM cannot start, Gecko cannot start. If Gecko cannot start, then there is no rendering engine for the application, essentially stopping whichever Mozilla-based app one might wish to run, before it even gets started.
Mozilla Hardware Acceleration and VNC sessions
I've been a Mozilla user since before Mozilla. I was a Netscape user back in the early days of Netscape for OS/2, when WebExplorer was kind of neat, but Netscape was much better.
Well, as an avid user and supporter of SeaMonkey, both personally and professionally, I was pleased to see us (the SeaMonkey community) stay on the same Gecko with 2.1+ as Firefox 4+. One of the nice things introduced in Gecko 2 is hardware acceleration. Unfortunately, I have suffered with some nasty screen corruption on my ThinkPad T43 (SXGA+ 1400x1050, ATI Mobility Radeon X300) with hardware acceleration enabled (as it is by default). Mainly, this corruption manifests itself as mouse artifacts (droppings?) in the browser window and particularly in expanded menus. However, as this seems to only be happening on my T43 under eComStation 1.2R (one of these days, I'm going to upgrade eCS on this notebook to 2.1), I don't give it much thought when upgrading Mozilla apps on other systems, and leave acceleration set to the default.
BTW, to disable (hardware) layer acceleration, simply toggle the user pref layers.acceleration.disabled to true. See more on this, below.
The Browser Wars Continue…
An interesting (if inaccurate) read over at USA Today...
The author makes the (by now familiar) statement, "A decade ago, the Web browser market was a two-horse race between Microsoft's Internet Explorer (MSFT) and Netscape Communications' Navigator. (We all know who won.)" We do? Let's see if we can put some perspective on that concept...
Setting aside the innovation by Netscape Communications (the folks who brought us SSL, for example), and taking only the browser product (Netscape Navigator) and its progeny into account, there is a long line of succession and it is clear (to me, at least) that not only are the browser wars not over (by a longshot), but that just as in covert warfare, it is often difficult to tell who is really winning the overarching conflict.
Wikipedia has a fairly complete history of Mosaic and Netscape, and the companies which produced those products. I will not spend the time reiterating all of that information here, except to say that while there are a mere handful of browsers based on IE code, I can think of no less than twenty open source and commercial browser and browser-related offerings which are based on the Gecko rendering engine (the underlying engine in all Mozilla-based browsers).
Don't be misled concerning the reports of IE usage vs other browsers, either. Considering that IE is an integral component of the Windows desktop, and that every time the Windows OS accesses the net for updates, registration, and such, it utilizes the IE engine, it is simply not possible to tell how many of those people actually use Mozilla-based browsers for their real-time browsing, considering the number of Windows-based systems in use as compared to other desktop operating systems (and this, too, is likely to change over time).
So, as with all of these statistical reports, take the author's conclusions with a grain of salt. I am posting this from:
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.15) Gecko/20101110 Lightning/1.0b2 Mnenhy/0.8.3 SeaMonkey/2.0.10
which is built 100% on Mozilla code.
PS - One other comment form the article referenced above, and one with which I wholeheartedly agree:
Several financial institutions don't work well with Chrome or Firefox, forcing their online banking customers to use older, less secure versions of IE.
LOL...