I'd like to embed you, in the worst way (plus: Sony sells out)

Periodically I read these "best browser for PowerPC" blog postings, which generally have the scientific testing rigour of an addled camel in heat and are about as intelligible. Generally some version of WebKit is proposed as the winner based on highly objective criteria like how quickly they can get a Kate Upton pinup to load, and this is how WebKit will eat the world.

Snark aside, I think a lot of people don't really understand that most of the WebKit browsers, including Safari itself, are merely shells around the system WebKit framework; they simply embed it. With Gecko browsers like this one, SeaMonkey, AuroraFox, etc., the browser is the framework. While Camino was a little more complex because it actually did embed Gecko as a framework on which it depended, it included its own copy because there is obviously no system Gecko (and embedding is no longer supported anymore anyway; maybe it should be). When you update a Gecko browser, you get all the security fixes in the core as well because a new core comes with it. This is not true for a WebKit shell.

Obviously, this has a security concern because while the browser shell may be up to date, there could be security flaws in the system framework, and these in turn become security flaws of any app that uses it. For example, Stainless, iCab (4 and up), Roccat, Safari, etc., all are just shells on the system WebKit and thus become vulnerable to any flaw that affects it. If you open up the app package, they don't contain WebKit themselves, which is why they're so small (there is one exception I know of).

If you're going to use one of these browsers, you need to update the system WebKit framework at the same time and the only way to do that I know of is Tobias' Leopard WebKit (or, TenFourKit on 10.4, which is somewhat less current). By installing that, you simultaneously update the core of any browser shell that uses it. (It should also make you think hard about what the difference is between these browsers, functionally. Although they may have certain boutique value-added features, arguably the only WebKit shell doing anything interesting at the system level is Stainless.) If you're not going to use TenFourFox or AuroraFox or SeaMonkeyPPC, then please at least keep WebKit up to date, and that's the only way I know of for PowerPC OS X.

Well, actually, there's one other, the shining exception: OmniWeb. OmniWeb, alone among WebKit browsers, includes its own updated copy of the WebKit framework. This allows it to be more current than Safari 4 on 10.4, for example, and it is my preferred choice when I need to check an HTML layout against WebKit. No one know how much longer OmniWeb will still be compatible with 10.4 (or for that matter 10.5), but that's your other option, and OmniWeb has always been a very solid product.

Other news. This week, Sony introduced the PlayStation 4, and announced that they were ditching IBM's custom Cell CPU for a relatively pedestrian AMD x86 multi-core (and a crapload of GDDR5 RAM, though its latency with the CPU is a bit concerning). AMD has really lost the battle with Intel in a big way; all of us probably remember during the NetBurst era when AMD routinely ate Intel's lunch in benchmarks and price-performance ratio, but those days are long gone ever since Intel came out with the Core microarchitecture. However, AMD is cash-poor and business-hungry, and they probably offered their chips to Sony very cheaply. Really, it's more of an indictment of Cell and how it never achieved IBM's or Sony's goals, which was always an odd duck processor. Recall that Cell is a PowerPC core of modest means, the "PPE" Power Performance Element, surrounded by "SPEs" Synergistic Programming Elements, which are special-purpose coprocessors that must be primed by the PPE for execution. The PPE main core, the PowerPC portion, was straight-forward enough to program but could not achieve sufficient performance on its own, and the satellite SPEs always bedeviled developers with their almost purely SIMD instruction set and dependency on the PPE. Why Sony didn't do what Microsoft did and ask for a more typical multi-core CPU -- the Xbox 360's Xenon is, in fact, just three modified PPEs -- is totally unclear to me. It also means that it will be very difficult for the PS4 to run PS3 games in emulation and even recompiling them for the new architecture is not guaranteed to work since there are in fact two architectures they must account for.

When 20 hits beta 2, the next unstable port will begin.

17.0.3 now available

... from the Downloads tab (read the release notes). If you are a Spanish or Russian speaker, please also try our langpacks from issue 61; those will be released with 17.0.3 on Monday assuming no problems.

I love you

But, you know, not in that way. Instead, I love you in this way: 19.0 is now officially released, the first "final" version of our unstable branch. Mozilla fixed quite a few bugs between the beta 1 we originally released and this one, including the font aliasing issue that annoyed Chris, a scrolling speed regression, some repainting errors and at least two memory leaks (one in proxy support, one in regular expressions). For our part, I have modified our atomic routines further to be totally syncless (issue 205), and this improves performance further on multiprocessor Macs, including this quad. Overall, I'm pretty happy with 19.0. Get it from the Downloads tab.

If you look through the changesets, you will also see a new js/src/ion/ppcosx directory for our IonMonkey port so that we can be ready when Mozilla unveils their new JavaScript "Baseline" compiler using that backend (which presumably will replace the JaegerMonkey JavaScript compiler we use now at that point). IonMonkey is still going to be a tremendous amount of work, but I'm beginning to wrap my head around its concepts a little and the strange things it does on the stack. I'm trying to get the trampoline at least operational so I can test code generation even if it doesn't actually do anything useful, but we're not even to the point where it can build, and I'm really hoping Mozilla doesn't remove JaegerMonkey until at least the next ESR since we're still the only lonely outside port even in progress for Ion.

I'm continuing to do more research into issue 193, which is currently our largest performance issue (the URL I use for testing is local radio station KFI). I'm beginning to suspect the problem is Apple's atrocious pthreads implementation. Is it as bad on 10.5 as it is on 10.4? Your comments suggested. If it's really just this bad, it may not be fixable without Mozilla doing a deep dive on the layout code, which I bet they won't.

17.0.3 will have issue 205 also since it works very well, plus the Spanish and Russian langpacks, plus Claudio's Intel patches. Look for that over the weekend for release on Monday.

Opera knows the power of the Dark Side of the WebKit Force

Opera announced today that their custom HTML/CSS rendering engine, Presto, will be decommissioned in place of WebKit (specifically, it will use code from Google Chrome's open source version Chromium, including presumably V8, its benchmark-obsessed JavaScript compiler). Essentially this turns Opera into little more than a Chrome shell, and liberates the company from the significant development resources they had to invest in Presto/Carakan's maintenance.

I have ranted multiple times in E-mail, here and elsewhere about the danger an unchecked WebKit de facto monopoly holds for the Web. We damned Internet Explorer when it crushed Netscape, and in a few years we will damn WebKit in the same way. Already WebKit, based on its tremendous installed base on iOS and Android, is the uncontested dominant rendering platform on mobile, and while Opera represented only a fraction of the desktop browsing market, it was a large player in mobile and feature handsets which will now be ceded to WebKit in effect. More importantly, it represented another way to render HTML 5 that kept developers honest instead of "developing for WebKit." Now all that's left, other than very tiny specialized engines like Dillo and NetSurf, is Trident (IE), Gecko, and the swelling juggernaut of WebKit largely due to Google Chrome, Safari and a host of other minor shell browsers like Midori, OmniWeb, possibly the future Camino (if it even makes it to 3.0) and now Opera itself.

Every so often I get questions about why I bother with a Firefox port "when Google Chrome would work so much better." Besides the fact I dispute the premise, and that Google Chrome or Chromium has never run on a big-endian platform, let alone PowerPC, the answer simply comes down to trust. The Mozilla Foundation is non-profit, community-invested and dedicated to open standards and the Web; they have no interest in lock-in, only to act as a standards-compliant supported option. Mozilla is kept honest because of its competition and its high level of user and volunteer commitment, including yours truly. While WebKit is open source, allowing people like Tobias to maintain Leopard WebKit, it is still largely controlled by Apple and Google because they have the largest financial and practical interest in it (not to mention their proprietary browsers based on it) and its gatekeepers and reviewers are Apple and Google staff. Their browsers are revenue generators, and while WebKit is important to Apple from the context of iTunes and the App Store interface (remember that Safari is only the browser manifestation), Chrome is unapologetically Google's effort to optimize their user experience. It is less important to them what happens to the rest of the Web than that their users have a good experience (and preferably the superior experience) with Chrome on their services (preferably their pay services), and it has already been demonstrated that it is also less important to them the user experience of their services on other browsers.

None of that is unreasonable per se, but it is unreasonable, and even dangerous, when the rendering core that they have a large stake in and modify for their purposes continues to accumulate market share. The standards canard is particularly insidious; "standards" are proposed and immediately implemented with a vendor prefix, but no one else may have implemented them or done so in the same way. Vendor prefixes again are not inherently bad and are necessary for proper testing and review, but they become another means for lock-in when people start developing their code for the set of vendor prefixes in their target browser to the exclusion of other rendering libraries. When WebKit is seen as the dominant rendering system, people only write code that works in WebKit, just as they did for Internet Explorer, and their dominant market position is only reinforced.

I'm a free-markets bastard, but a free market can only exist as long as there is adequate competition. The desired state of business in a particular industry is rent-seeking monopoly, and that's as bad here as it is with your electric bill. Opera Presto was a well-regarded standards-compliant alternative to WebKit which is now gone. The possible future outcome of a single browser rendering core means not only the loss of the community standards process and standardization around its attendant and sometimes significant quirks, but locks the way we use the Web in the hands of a governance process where the open Web's welfare is only secondary.

FWIW: New Google Groups, you suck, and here's the petition that says so

Continuing-on-in-the-vein-of-shame-dept.

Usually I think Change.org petitions are silly and/or self-serving, but this one I like. If you haven't noticed, Google Groups is now infested with JavaScript, and you have to take steps to get away from it or pick the old Groups (or use Classilla, which doesn't get a choice) and live with an ominous message that the world will end at some unspecified date. Now, yes, it's a free service, and we already mooch off Google for hosting our binaries and this blog and our issues list, so beggars can't be choosers, but just try using Google Groups on a slow system even with our finely tuned JavaScript JIT. I don't understand what was broke that they had to "fix."

17.0.3 and 19 final should be coming out this weekend. If you haven't tried the new langpacks for Russian and Spanish, see issue 61. They'll be rolled out at the same time.

Namin' and shamin'

If you bought this, you better ask for your money back. This is nothing more than the old brown Flash 10.1 with the version number bump, same as you get anywhere else. Notice that we are specifically warned away because of our plugin policy, so I will now advertise TenFourFox as protecting against charlatans too. What scam will they think of next?

Spanish and Russian translation packs available

Chris, who handles our localization/internationalization efforts, has offered for testing Spanish and Russian translations in issue 61. If these look good and work well, I plan to roll them out with 17.0.3, which is scheduled for 19 February. As a reminder, translation packs are only for the current stable branch release; there will not be l10n/i18n packs for unstable releases since it is too much of a load on our translators.

The Russian installer right now displays its prompts in English, although everything works fine in the browser and properly appears in Cyrillic. Rather than transliterate the Russian words from Cyrillic to Roman text, it was decided just to leave it in English. The reason is that our installers are based on AppleScript and AppleScript in 10.4 seems not to like any character encoding other than MacRoman (no UTF-8, no UTF-16). If anyone has a workaround for this, post it to issue 61 as well, since the Polish version is also somewhat affected by this.