Showing posts with label mozilla. Show all posts
Showing posts with label mozilla. Show all posts

Tuesday, September 1, 2020

I'm trying really hard to like the new Android Firefox Daylight. Really, I am.

I've used Firefox for Android nearly since it was first made available (I still have an old version on my Android 2.3 Nexus One, which compared with my Pixel 3 now seems almost ridiculously small). I think it's essential to having a true choice of browsers on Android as opposed to "Chrome all the things" and I've used it just about exclusively on all my Android devices since. So, when Firefox Daylight presented itself, I upgraded, and I'm pained to say I've been struggling with it for the better part of a week. Yes, this is going to be another one of those "omg why didn't I wait" posts, but I've tried to be somewhat specific about what's giving me heartburn with the new version because it's not uniformly bad and a lot of things are rather good, but it's still got a lot of rough edges and I don't want Daylight to be another stick Mozilla gives to people to let them beat them with.

So, here's the Good:

Firefox Daylight is a lot faster than the old Firefox for Android. Being based on Firefox 79, Daylight also has noticeably better support for newer web features. Top Sites are more screen-sparing. Dark mode is awesome. I like the feature where having private tabs becomes a notification: tap it and instantly all your naughty pages private browsing goes poof (and it's a good reminder they're open), or, if this doesn't appeal to you, it's a regular notification and you can just turn it off. Collections sound like a neat idea and I'll probably start using them if things get a little unwieldy. I'm not a bar-on-the-bottom kind of guy myself, but I can see why people would like that and choice is always good.

All this is a win. Unfortunately, here's the Bad I'm running into so far:

This has been reported lots of places, but the vast majority of the extensions that used to work with the old Firefox suddenly disappeared. For me, the big loss was Cookie Quick Manager, which was a great mobile-friendly way to manage cookies. Now I can't. Hope I don't screw up trying to get around those paywalls sites storing data about me. At least I still have uBlock Origin but I don't have much else.

Firefox Reader doesn't universally appear on pages it used to. Sometimes reloading the page works, sometimes it doesn't. This is a big problem for mobile. Worse, the old hack of prepending an about:reader?url= doesn't seem to work anymore.

Pages that open new windows or tabs sometimes show content and sometimes don't. This actually affects some of my sites personally, so I filed a bug on it. Naturally, it works fine in desktop Firefox and Chrome, and of course the old Android Firefox.

Oh, and what happened to the Downloads list? (This is being fixed.)

Now, some pesky Nits. These are first world problems, I'll grant, but my muscle memory was used to them and getting people onto a new version of the browser shouldn't upset so many of these habits:

When I tapped on the URL to go to a new site, I used to see all my top sites, so I could just switch to them with a touch. Now there's just a whole lot of empty space (or maybe it offers to paste in a URL left over in the clipboard). I have to open a new tab, or partially type the URL, to get to a top site or bookmark. This might be getting fixed, too, but the description of exactly what's getting fixed is a little ambiguous. Related to this, if you enable search suggestions then they dominate the list of suggestions even if it's obvious you're typing part of a domain name you usually visit. In the old browser these were grouped, so it was easy to avoid them if you weren't actually searching.

I often open articles in private browsing mode, and then tap the back button to go to the regular tab I spawned it from. This doesn't work anymore; I have to either switch tab "stacks" or swipe away the private tab.

Anyway, that's enough whining.

I don't really want to have to go back to the old Firefox for Android. I think the new version has a lot to recommend it, and plus I really despise reading bug reports in TenFourFox where the filer drops a bug bomb on my head and then goes back to the previous version. Seriously, I hate that: it screams "I don't care, wake me when you fix it" (whether or not it's really my bug) and says they don't have enough respect even to test a fix, let alone write one.

So I'm sticking with Firefox Daylight, warts and all. But, for all its improvements, Daylight needs work and definitely not at a time when Mozilla has fewer resources to devote to it. I've got fewer resources too: still trying to work on TenFourFox and keep Firefox working right on OpenPOWER, and now I may have to start doing PRs on the Android browser if I want that fixed also. It just feels like everything's a struggle these days and this upgrade really shouldn't have been.

Saturday, August 15, 2020

TenFourFox FPR26b1 available (after all, Mozilla's not dead yet)

TenFourFox Feature Parity Release 26 beta 1 is now available (downloads, hashes, release notes). There isn't a great deal in this release due to continued heavy workload at my regular job and summer heat here in excessively sunny Southern California making running the G5 and the Talos II at the same time pretty miserable, and I also had the better part of a week laid up ill to boot (note: not COVID-19). Still, this hopefully completes the work on DOM workers and the usual security updates, which will switch to 78ESR starting with FPR27. All going well, it will be released on August 25.

With much of the low-hanging fruit gone that a solo developer can reasonably do on their own, for FPR27 I would like to resurrect an old idea I had about a "permanent Reader mode" where once you enter Reader mode, clicking links keeps you in it until you explicitly exit. I think we should be leveraging Reader mode more as Readability improves because it substantially lowers the horsepower needed to usefully render a page, and we track current releases of Readability fairly closely. I'm also looking at the possibility of implementing a built-in interface to automatically run modifier scripts on particular domains or URLs, similar to Classilla's stelae idea but operating at the DOM level a la Greasemonkey like TenFourFox's AppleScript-JavaScript bridge does. The browser would then ship with a default set of modifier scripts and users could add their own. This might have some performance impact, however, so I have to think about how to do these checks quickly.

A few people have asked what the Mozilla layoffs mean for TenFourFox. Not much, frankly, because even though the layoffs affect the Mozilla security team there will still be security updates, and we'll continue to benefit as usual from backporting those to TenFourFox's modified Firefox 45 base (as well as downstream builders that use our backports for their own updates to Fx45). In particular I haven't heard the layoffs have changed anything for the Extended Support Releases of Firefox, from which our continued security patches derive, and we don't otherwise rely on Mozilla infrastructure for anything else; the rest is all local Floodgap resources for building and hosting, plus Tenderapp for user support, SourceForge for binaries and mirrors and Github for source code, wiki and issues.

But it could be a bigger deal for OpenPOWER systems like the Talos II next to the G5 if Mozilla starts to fade. I wrote on Talospace a good year and a half ago how critical Firefox is to unusual platforms, not least because of Google's general hostility to patches for systems they don't consider market relevant; I speak from personal experience on how accepting Mozilla is of Tier 3 patches as long as they don't screw up Tiers 1 and 2. Although the requirement of a Rust compiler is an issue for 32-bit PowerPC (and Tiger and Leopard specifically, since we don't have thread-local storage either), much of the browser still generally "just builds" even in the absence of architecture-specific features. Besides, there's the larger concern of dealing with a rapidly changing codebase controlled by a single entity more interested in the promulgation of its own properties and designing their browser to be those services' preferred client, which is true whether you're using mainline Chrome or any of the Chromium-based third-party browsers. That may make perfect business sense for them and for certain values of "good" it may even yield a good product, but it's in service of the wrong goal, and it's already harming the greater community by continuing to raise the barrier to entry for useful browser competition. We damned IE when Microsoft engaged in embrace, extend and extinguish; we should make the same judgment call when Google engages in the same behaviour. We have no spine for meaningful anti-trust actions in the United States anymore and this would be a good place to start.

Tuesday, September 26, 2017

TenFourFox FPR3 available ... when SourceForge is (also: Fx57 is yugly)

Sorry, everyone. I am well aware that SourceForge is down and you can't download TenFourFox FPR3 (or, for that matter, Classilla) right now. I don't have any control over that. If this keeps up more than a day or two, we'll see if we can get alternative hosting up somewhere.

Also, my office PC (Windows 7) is now on the Firefox 57 beta and it's ... really garish and ugly looking. Switching the layout to Compact and the theme to Light helps a little with the tab bar, but the KITT loading tab animation is distracting, the icons manage to be intrusive and bland simultaneously, and the new logo is a bad LSD trip (to say nothing of the fact half my extensions stopped working, and while I knew that was coming, most of them have no replacement because the APIs don't yet exist). While I thought Australis was a step backwards in terms of utility, at least it had some design consistency. Photon, on the other hand, is all over the place and it's an unwelcome change on top of everything else. I'm almost afraid to update Firefox on the MacBook Air.

But, to be fair, it is palpably faster. Much faster. I certainly can't argue that. Nevertheless, the compromises made are such that if it weren't for Google's relentless commitment to snoop on everything I do, I have to candidly say I'm not sure I'd be sticking with the new Firefox.

Saturday, July 1, 2017

OverbiteFF will cease functioning with Firefox 56 (we need WebExtension sockets)

For those unfamiliar, TenFourFox and Classilla aren't my only Mozilla-related projects; the other one I've maintained for some time is OverbiteFF, which adds Gopher support back to Firefox as a first-class citizen. It does so by implementing nsIChannel and nsIProtocolHandler objects which speak Gopher and allows everything to "just work" like any other URL. Because of how the protocol works, the add-on also enables whois and finger protocol support with a little bit of URL gyration, and to this day there is a small but dedicated userbase.

As of Firefox 56, it is my understanding that non-multiprocess-compatible extensions will no longer be supported, which is currently in nightly. Even if I were able to make OverbiteFF MP compatible, however (there were some technical hurdles to be overcome when I tried), it is highly dependent on XPCOM and Firefox 57 will be the end of that. As a result, OverbiteFF in its current form will cease functioning with Firefox 56. It will, of course, continue to work with TenFourFox and Firefox 52ESR, so I would recommend switching to 52ESR as a stopgap if you need to run XPCOM-dependent extensions like this one and are not lucky enough to have a Power Mac. For Firefox Android users, Overbite Android works wonderfully as an external application and Firefox Android will hand Gopher URLs to it; I use my own work on a Google Pixel XL with Android 7.1.2.

Unfortunately, there is no way to make OverbiteFF compatible with WebExtensions, even with reduced functionality: no one has implemented TCP socket access for extensions, and the protocol handler support is not only incomplete but actually intentionally excluded the Gopher protocol in URLs (so I can't even implement it like the old Overbite Chrome, which rewrote requests for any of the available Gopher->HTTP gateways). I'd submit a patch to whitelist gopher for the latter but there's been no motion on dealing with the standards clash that caused it, and there's not even an API description for WX socket support, let alone code written to implement it.

Clearly OverbiteFF is hardly alone among extensions in these requirements (for example, uProxy, Chatzilla, FireFTP and FireSSH will all stop working too), but I'm particularly bitter about this because its genesis came from the protracted end of Gopher support in Firefox 4. The tl;dr from that bug was, paraphrased straight from Mountain View, it's being yanked and you can't stop it, so learn XPCOM and write an add-on and maintain the feature yourself. Well, I did, it worked, people used it, and now it's going to stop working and unless motion occurs on these APIs I won't be able to make it work ever again in the future. You can post all the happy talk about how wonderful the end of XPCOM add-ons is for paying back Gecko's technical debt and I'm not going to dispute that, but that doesn't mean it doesn't suck. On the eve of WebExtensions' full takeover it feels like yet another broken promise.

Please, let's see motion on these and related APIs soon.

Wednesday, September 28, 2016

Firefox OS goes Tier WONTFIX

I suppose it shouldn't be totally unexpected given the end of FirefoxOS phone development a few months ago, but a platform going from supported to take-it-completely-out-of-mozilla-central in less than a year is rather startling: not only has commercial development on FirefoxOS completely ceased (at version 2.6), but the plan is to remove all B2G code from the source tree entirely. It's not an absolutely clean comparison to us because some APIs are still relevant to current versions of OS X macOS, but even support for our now ancient cats was only gradually removed in stages from the codebase and even some portions of pre-10.4 code persisted until relatively recently. The new state of FirefoxOS, where platform support is actually unwelcome in the repository, is beyond the lowest state of Tier-3 where even our own antiquated port lives. Unofficially this would be something like the "tier WONTFIX" BDS referenced in mozilla.dev.planning a number of years ago.

There may be a plan to fork the repository, but they'd need someone crazy dedicated to keep chugging out builds. We're not anything on that level of nuts around here. Noooo.

Wednesday, March 16, 2016

Après moi, le Tier-3 holocaust

Well, it finally happened: Mozilla's going to end support for 10.6-10.8. Actually, I'm surprised it took this long:

The motivation for this change is that we have continued failures that are specific to these old operating systems and don't have the resources on engineering teams to prioritize these bugs. Especially with the deployment of e10s we're seeing intermittent and permanently [sic] failures on MacOS 10.6 that we are not seeing elsewhere.

This confirms my suspicions that Electrolysis would have been seriously problematic on 10.4 and 10.5 given the permafails Mozilla is seeing on 10.6, even if we got it to compile (it doesn't even do that on Tiger yet). That's why we're forking after 45ESR, which doesn't have E10S enabled by default.

Interestingly, Mozilla's plan is nearly identical to ours: move 10.6-10.8 users onto 45ESR as well so that they'll still get a year-ish of support on that branch in a sort of graceful wind-down. The difference is that we plan to make hacks to the core to support certain post-45 features (making TenFourFox essentially into an OS X Classilla), and of course backport future security updates from 52ESR and so on. I guess if you're running Snow Leopard you can use TenFourFox post-fork with the usual limitations, but I still currently have no plans for an Intel-native version unless someone steps up to maintain it (although I have a 10.6 machine that might benefit, I just don't have the time right now).

The interesting part is that Mozilla still has more users on 10.6 than 10.7 and 10.8 combined, and 10.6 still accounts for something like 13% of all Firefox Mac users. As late as 2014 19% of all Macs ran it. Snow Leopard really is the Windows XP of the Intel Mac.

Mozilla also did a wholesale pruning of most of the other Tier-3 ports, as part of shifting from autoconf:

Following our official move off autoconf, the core build team is faced with having to convert more than 17k lines of shell+m4. A large part of those are to support Tier-3 platforms such as Solaris, HPUX, AIX, etc., with compilers that are not MSVC, GCC or clang (e.g. SunPro, XL C++...). To simplify the conversion, from day one, we will support only the following set of platforms and toolchains:

Platforms:
- Linux
- Android
- Windows
- OSX/Darwin
- multiple flavors of BSD (kFreeBSD, FreeBSD, DragonFly, NetBSD, OpenBSD)

Toolchains:
- MSVC
- GCC/mingw
- clang
- clang-cl

This is a little different than the end of 10.[678] support, however:

This does not mean Firefox/Gecko/etc. will forever drop support for these platforms and toolchains. It simply means we can't assess what parts of the shell+m4 are relevant (as opposed to cruft accumulated over years or decades) and will continue to work (since we don't have automation to verify these configurations).

[...]

The good news is that dropping support now will help make the overall conversion happen sooner, *and*, once the conversion is done, interested parties can come back with working patches that should be easier to write.

My SPARC Ultra-3 laptop (a rebadged Tadpole Viper) runs an ESR build of Firefox just fine in Solaris 10, the last Solaris supported on that platform. Unfortunately I don't have the Sun compiler, or I'd take a whack at building it myself. At least someone out there is still popping out contrib builds for SPARC and i386, but I don't know if they will continue to.

On the other hand, some of those other platforms haven't worked in years. I know of a Firefox 3.6 for AIX, at least on POWER (my PowerPC AIX systems barf on it), but HP/sUX ended support somewhere around 3.5.9 and was always a mess to build (I hated HP's ANSI C-compiler back in the day when I had to administer those systems). I even remember seeing some Digital UNIX/Tru64 stuff deep within xpcom/, but I can't imagine full support persisted much beyond Mozilla 1.8 something. None of the rest of them got much further.

Really, these are all dusty legacies of how portable the old codebase used to be. At one time, Netscape ran on Windows (as early as 3.1), Mac OS (System 7 and up), OS/2, Linux, Digital UNIX (Tru64), SunOS 4, VMS (VAX and Alpha), Solaris, BSD, HP/UX, IRIX, AIX, and probably some other minority ports I don't remember, and all with almost total feature parity. In fact, I myself have personally used every single one of those ports at one time or another. As late as Mozilla 1.7 almost all of those platforms were still working (SunOS 4 and VMS were gone, and Mac OS was replaced with OS X, but the rest were still functioning), but Firefox 2 and 3 gradually winnowed the rest, and by Firefox 4 it was pretty much just Windows, OS X (including us), Linux, the BSDs and Solaris. Soon it'll just be those OSes on x86-64 and ARM.

So, while it may have been hell to maintain, that's a lot of history gone that I personally lived through and good cause or not it still makes me sad to see these last remnants drift away, even on the abandoned platforms. (You can cram it if you're going to post some uninsightful comment like "paying back technological debt" or "no one maintains platforms for free." I'm well aware of the cost of cruft. That doesn't mean it doesn't have historical value, and that historical value should be appreciated, even if doing so is best done in archives rather than current code bases.) It used to be neat to compare how heterogeneous and diverse computing platforms were back in the day, but sadly today's platforms are more alike than they're different, and I think we've lost something there.

It's not really fun anymore.

Tuesday, December 8, 2015

So long, Firefox phones

Fresh from Mozilla's internal revelation they'd like to jettison Thunderbird as a drag on Firefox development (sure to rankle our Tenfourbird builder in the land of the Rising Sun), Mozilla has now announced the end of the Firefox OS smartphone.

I can't say I'm surprised. I liked FxOS as a user, but its application support was dismal (so I could not ditch my Nexus 5, nor could I truly dogfood any Firefox device), and FxOS seemed to only be offered as an option on truly awful hardware. In my case, it was the so-bad-it's-terrible Geeksphone Revulsion Revolution, branded as their developer unit after the whimpering fail of the Peak. True to form, when I actually finally got one, it turned out to be an unmitigated steaming heap and essentially ensured I would never buy a Geeksphone device ever again. Yes, it was that bad. And this was supposed to be their developer device, to get people actually excited about the platform!

That said, I'm sad to see this development (even if I'm not at all shocked), because even though FxOS will live on in some form as an open source project I predict it'll eventually go the benignly neglected way of things like Firefox for webOS (which, having recently acquired an HP Veer for snickers and fighting with endian problems in novacomd, would be really handy about now). That's bad for us in Power Mac land because the improvements to boost Firefox performance on constrained mobile devices also help with our now decade-plus computers. Time will tell if Mozilla decides to kill the entire project as well, not just shipping Firefox phones.

TenFourFoxBox so far has been a huge success. I should publicly mention Mike Hommey's comment in the last blog entry: yes, the true successor to WebRunner is the webapp runtime that Firefox presently comes with, but the webapp runtime doesn't work on 10.4 and needs quite a bit of hacking to do so, and since we weren't using it anyway I could just implement an even lighter chrome and make it even faster. There will be some adjustments to allow people with differently-named executables to work (as well as an override version in case you want to use a specific version of the browser to run your foxboxes), and we need to implement a component for certain sites that try to enumerate navigator.* properties (Chase was the main offender), but otherwise it's been very well received. 1.0 will appear after 38.5.0 and will receive its own website at that time.

Speaking of, I haven't had a lot of time to do much else with 38.5 or the occasional test complaints about the MP3 decoder due to time constraints and finishing my Master's degree, but the MP3 decoder will be enabled and we'll gather some data points to figure out which encoders minimp3 doesn't like (after all, the fact it can play most MP3 files is better than none). There will also be a patch for bug 1181977 to fix the empty Application menu in foxboxes (remember to quit any running foxboxes before you upgrade the browser), and a custodial cleanup after issue 308. Watch for it this weekend for release next week.

Monday, August 24, 2015

Okay, you want WebExtensions API suggestions? Here's three.

Not to bring out the "lurkers support me in E-mail" argument but the public blog comments are rather different in opinion and tenor from the E-mail I got regarding our last post upon my supreme concern and displeasure over the eventual end of XPCOM/XUL add-ons. I'm not sure why that should be, but never let it be said that MoFo leadership doesn't stick to their (foot)guns.

With that in mind let me extend, as an author of a niche addon that I and a number of dedicated users employ regularly for legacy protocols, an attempt at an olive branch. Here's the tl;dr: I need a raw socket API, I need a protocol handler API, and I need some means of being able to dynamically write an document/data stream and hand it to the docshell. Are you willing?

When Mozilla decommissioned Gopher support in Firefox 4, the almost universal response was "this shouldn't be in core" and the followup was "if you want it, it should be an add-on, maintained by the community." So I did, and XPCOM let me do this. With OverbiteFF, Gopher menus (and through an analogous method whois and ph) are now first class citizens in Firefox. You can type a Gopher URL and it "just works." You can bookmark them. You can interact with them. They appear no differently than any other web page. I created XPCOM components for a protocol object and a channel object, and because they're XPCOM-based they interact with the docshell just like every other native core component in Necko.

More to the point, I didn't need anyone's permission to do it. I just created a component and loaded it, and it became as "native" as anything else in the browser. Now I need "permission." I need APIs to do what I could do all by myself beforehand.

What I worry is that Mozilla leadership is going to tick the top 10 addons or so off as working and call it a day, leaving me and other niche authors no way of getting ours to work. I don't think these three APIs are either technically unrealistic or lack substantial global applicability; they're foundational for getting new types of protocol access into the browser, not just old legacy ones. You can innovate nearly anything network-based with these three proposals.

So how about it? I know you're reading. Are you going to make good on your promises to us little guys, or are we just screwed?

Friday, August 21, 2015

Mozilla's future footgun add-on policy (or, how MoFo leadership is getting it totally wrong)

So long, Firefox. It was nice to know you.

First, Electrolysis. As mentioned, we won't support it in TenFourFox; we would need to implement a userland spawn implementation for 10.4 from scratch for starters, and I suspect that the overhead required will end up performing substantially worse on old Macs plus the inevitable OS bugs it will undoubtedly uncover. Currently Mozilla is predicting Electrolysis will reach the release channel by Fx43, which I find incredibly optimistic given predictions for Australis which slipped deadline after deadline, but it's clear Electrolysis' public unveiling in the relative near future is inevitable. Once it becomes no longer possible to launch the browser in single-process mode, likely one or two versions after, that's the end of source parity. My suspicion is that it will actually reach release by Fx45, which is the next ESR anyway, and there should be an emergency fallback to single-process that we can exploit to keep us running at ESR parity for the last time.

To facilitate addons in the new e10s world, Mozilla is effectively announcing that XPCOM/XUL-based addons are now deprecated because of their highly synchronous nature. (Technically, they'll be deprecated six months after Electrolysis goes golden master, and completely unsupported and/or incompatible within six months after that, but as far as I'm concerned announcing a future deprecation is the same as deprecating it now.) This sucks because the use of XPCOM and XUL in the Mozilla Suite and later Firefox and SeaMonkey meant easy cross-platform add-ons that could do powerful things like implementing a completely new protocol within the browser. Although jetpack addons will still work, sort of, any jetpack addon that requires chrome features is subject to this policy also. Mozilla will be enforcing this brave new XUL-free world by refusing to sign addons that rely on XPCOM or XUL in this later timeframe, which dovetails nicely with not allowing unsigned addons starting with Firefox 42. (Parenthetically I don't agree with the mandatory signing policy, and if there is a TenFourFox 45 it will disable this feature. I don't port Gecko code for the walled garden, guys, thanks.)

Calling this a footgun and the future death of Firefox is not merely hyperbole. I suspect, and I suspect Mozilla is ignoring the fact, that many Firefox users use it because of the presence of such powerful addons that just can't be replicated in other browsers. Chrome, for example, doesn't have near the functionality because it doesn't expose it, and its addons are much less useful in general. But Mozilla is not content to merely shoot themselves in the foot here; they've emptied the whole magazine into their leg by making the new add-on world based on the almost completely different WebExtensions API. WebExtensions is Blink-compatible, the engine powering Chrome. That means an author can easily create a much less functional addon that runs not only on Firefox but also on Chrome. Yup, you read that right: soon the only functional difference between Firefox and Chrome at this rate will be the name and the source tree. More to the point, many great classic addons won't work in the new API, and some addons will probably never be made to work with WebExtensions.

Riddle me this, Batman Mozilla leadership: if the addons are the same, the features are the same, the supported standards are the same, the interface is converging and Mozilla's marketshare is shrinking ... why bother using Firefox? I mean, I guess I could start porting SeaMonkey, although this announcement probably kicks the last leg out from under that too, but does Firefox itself, MoCo/MoFo's premier browser brand, serve any useful purpose now? Don't say "because it makes the web free" -- people can just go download and compile WebKit, which is open source, well understood and widely available, and they can even usefully embed it, another opportunity Mozilla leadership shortsightedly threw away. They can fork it like Google did. They can throw a shell around it. Where's the Gecko value now?

Maybe this is a sign that the great Mozilla experiment has finally outlived its usefulness. And frankly there won't be much value in a Gecko-based browser or even a Servo-based one that works exactly the same way as everything else; notice the absolute lack of impact Firefox OS is having on mobile, although I use and prefer Firefox Android personally just because I don't trust Chrome. Maybe that trust will be the only reason to keep using Firefox on any platform, because I certainly can't think of anything else.

Meanwhile, this weekend I'm rewriting TenFourFox wiki documentation on Github ahead of the impending read-only status of Google Code. Since this is true Markdown, I'm using Nathan Hill's SimpleMarkPPC since it works pretty well for simple documents of this type and runs on 10.4. I won't be copying over all the old release notes, but starting with 38.3 all future ones will be on Google Code as well. After that we'll work on the MP3 support to finalize it, and I've got a secret project to share hopefully next week.

Tuesday, February 24, 2015

Two victories

Busted through my bug with stubs late last night (now that I've found the bug I am chagrined at how I could have been so dense) and today IonPower's Baseline implementation successfully computed π to an arbitrary number of iterations using the nice algorithm by Daniel Pepin:

% ../../../obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1738423371907505
% ../../../obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.141625985812036

Still work to be done on the rudiments before attacking the test suite, but code of this complexity running correctly so far is a victory. And, in a metaphysical sense, speaking from my perspective as a Christian (and a physician aware of the nature of his illness), here is another victory: a Mozillian's last post from the end stages of his affliction. Even for those who do not share that religious perspective, it is a truly brave final statement and one I have not seen promoted enough.

Tuesday, January 27, 2015

And now for something completely different: the Pono Player review and Power Macs (plus: who's really to blame for Dropbox?)

Regular business first: this is now a syndicated blog on Planet Mozilla. I consider this an honour that should also go a long way toward reminding folks that not only are there well-supported community tier-3 ports, but lots of people still use them. In return I promise not to bore the punters too much with vintage technology.

IonPower crossed phase 2 (compilation) yesterday -- it builds and links, and nearly immediately asserts after some brief codegen, but at this phase that's entirely expected. Next, phase 3 is to get it to build a trivial script in Baseline mode ("var i=0") and run to completion without crashing or assertions, and phase 4 is to get it to pass the test suite in Baseline-only mode, which will make it as functional as PPCBC. Phase 5 and 6 are the same, but this time for Ion. IonPower really repays most of our technical debt -- no more fragile glue code trying to keep the JaegerMonkey code generator working, substantially fewer compiler warnings, and a lot less hacks to the JIT to work around oddities of branching and branch optimization. Plus, many of the optimizations I wrote for PPCBC will transfer to IonPower, so it should still be nearly as fast in Baseline-only mode. We'll talk more about the changes required in a future blog post.

Now to the Power Mac scene. I haven't commented on Dropbox dropping PowerPC support (and 10.4/10.5) because that's been repeatedly reported by others in the blogscene and personally I rarely use Dropbox at all, having my own server infrastructure for file exchange. That said, there are many people who rely on it heavily, even a petition (which you can sign) to bring support back. But let's be clear here: do you really want to blame someone? Do you really want to blame the right someone? Then blame Apple. Apple dropped PowerPC compilation from Xcode 4; Apple dropped Rosetta. Unless you keep a 10.6 machine around running Xcode 3, you can't build (true) Universal binaries anymore -- let alone one that compiles against the 10.4 SDK -- and it's doubtful Apple would let such an app (even if you did build it) into the App Store because it's predicated on deprecated technology. Except for wackos like me who spend time building PowerPC-specific applications and/or don't give a flying cancerous pancreas whether Apple finds such work acceptable, this approach already isn't viable for a commercial business and it's becoming even less viable as Apple actively retires 10.6-capable models. So, sure, make your voices heard. But don't forget who screwed us first, and keep your vintage hardware running.

That said, I am personally aware of someoneTM who is working on getting the supported Python interconnect running on OS X Power Macs, and it might be possible to rebuild Finder integration on top of that. (It's not me. Don't ask.) I'll let this individual comment if he or she wants to.

Onto the main article. As many of you may or may not know, my undergraduate degree was actually in general linguistics, and all linguists must have (obviously) some working knowledge of acoustics. I've also been a bit of a poseur audiophile too, and while I enjoy good music I especially enjoy good music that's well engineered (Alan Parsons is a demi-god).

The Por Pono Player, thus, gives me pause. In acoustics I lived and died by the Nyquist-Shannon sampling theorem, and my day job today is so heavily science and research-oriented that I really need to deal with claims in a scientific, reproducible manner. That doesn't mean I don't have an open mind or won't make unusual decisions on a music format for non-auditory reasons. For example, I prefer to keep my tracks uncompressed, even though I freely admit that I'm hard pressed to find any difference in a 256kbit/s MP3 (let alone 320), because I'd like to keep a bitwise exact copy for archival purposes and playback; in fact, I use AIFF as my preferred format simply because OS X rips directly to it, everything plays it, and everything plays it with minimum CPU overhead despite FLAC being lossless and smaller. And hard disks are cheap, and I can convert it to FLAC for my Sansa Fuze if I needed to.

So thus it is with the Por Pono Player. For $400, you can get a player that directly pumps uncompressed, high-quality remastered 24-bit audio at up to 192kHz into your ears with no downsampling and allegedly no funny business. Immediately my acoustics professor cries foul. "Cameron," she says as she writes a big fat F on this blog post, "you know perfectly well that a CD using 44.1kHz as its sampling rate will accurately reproduce sounds up to 22.05kHz without aliasing, and 16-bit audio has indistinguishable quantization error in multiple blinded studies." Yes, I know, I say sheepishly, having tried to create high-bit rate digital playback algorithms on the Commodore 64 and failed because the 6510's clock speed isn't fast enough to pump samples through the SID chip at anything much above telephone call frequencies. But I figured that if there was a chance, if there was anything, that could demonstrate a difference in audio quality that I could uncover it with a Pono Player and a set of good headphones (I own a set of Grado SR125e cans, which are outstanding for the price). So I preordered one and yesterday it arrived, in a fun wooden box:

It includes a MicroUSB charger (and cable), an SDXC MicroSD card (64GB, plus the 64GB internal storage), a fawning missive from Neil Young, the instigator of the original Kickstarter, the yellow triangular unit itself (available now in other colours), and no headphones (it's BYO headset):

My original plan was to do an A-B comparison with Pink Floyd's Dark Side of the Moon because it was originally mastered by the godlike Alan Parsons, I have the SACD 30th Anniversary master, and the album is generally considered high quality in all its forms. When I tried to do that, though, several problems rapidly became apparent:

First, the included card is SDXC, and SDXC support (and exFAT) wasn't added to OS X until 10.6.4. Although you can get exFAT support on 10.5 with OSXFUSE, I don't know how good their support is on PowerPC and it definitely doesn't work on Tiger (and I'm not aware of a module for the older MacFUSE that does run on Tiger). That limits you to SDHC cards up to 32GB at least on 10.4, which really hurts on FLAC or ALAC and especially on AIFF.

Second, the internal storage is not accessible directly to the OS. I plugged in the Pono Player to my iMac G4 and it showed up in System Profiler, but I couldn't do anything with it. The 64GB of internal storage is only accessible to the music store app, which brings us to the third problem:

Third, the Pono Music World app (a skinned version of JRiver Media Center) is Intel-only, 10.6+. You can't download tracks any other way right now, which also means you're currently screwed if you use Linux, even on an Intel Mac. And all they had was Dark Side in 44.1kHz/16 bit ... exactly the same as CD!

So I looked around for other options. HDTracks didn't have Dark Side, though they did have The (weaksauce) Endless River and The Division Bell in 96kHz/24 bit. I own both of these, but 96kHz wasn't really what I had in mind, and when I signed up to try a track it turns out they need a downloader also which is also a reskinned JRiver! And their reasoning for this in the FAQ is total crap.

Eventually I was able to find two sites that offer sample tracks I could download in TenFourFox (I had to downsample one for comparison). The first offers multiple formats in WAV, which your Power Mac actually can play, even in 24-bit (but it may be downsampled for your audio chip; if you go to /Applications/Utilities/Audio MIDI Setup.app you can see the sample rate and quantization for your audio output -- my quad G5 offers up to 24/96kHz but my iMac only has 16/44.1). The second was in FLAC, which Audacity crashed trying to convert, MacAmp Lite X wouldn't even recognize, and XiphQT (via QuickTime) played like it was being held underwater by a chainsaw (sample size mismatch, no doubt); I had to convert this by hand. I then put them onto a SDHC card and installed it in the Pono.

Yuck. I was very disappointed in the interface and LCD. I know that display quality wasn't a major concern, but it looks clunky and ugly and has terrible angles (see for yourself!) and on a $400 device that's not acceptable. The UI is very slow sometimes, even with the hardware buttons (just volume and power, no track controls), and the touch screen is very low quality. But I duly tried the built-in Neil Young track, which being an official Por Pono track turns on a special blue light to tell you it's special, and on my Grados it sounded pretty good, actually. That was encouraging. So I turned off the display and went through a few cycles of A-B testing with a random playlist between the two sets of tracks.

And ... well ... my identification abilities were almost completely statistical chance. In fact, I was slightly worse than chance would predict on the second set of tracks. I can only conclude that Harry Nyquist triumphs. With high quality headphones, presumably high quality DSPs and presumably high quality recordings, it's absolutely bupkis difference for me between CD-quality and Pono-quality.

Don't get me wrong: I am happy to hear that other people are concerned about the deficiencies in modern audio engineering -- and making it a marketable feature. We've all heard the "loudness war," for example, which dramatically compresses the dynamic range of previously luxurious tracks into a bafflingly small amplitude range which the uncultured ear, used only to quantity over quality, apparently prefers. Furthermore, early CD masters used RIAA equalization, which overdrove the treble and was completely unnecessary with digital audio, though that grave error hasn't been repeated since at least 1990 or earlier. Fortunately, assuming you get audio engineers who know what they're doing, a modern CD is every bit as a good to the human ear as a DVD-Audio disc or an SACD. And if modern music makes a return to quality engineering with high quality intermediates (where 24-bit really does make a difference) and appropriate dynamic range, we'll all be better off.

But the Pono Player doesn't live up to the hype in pretty much any respect. It has line out (which does double as a headphone port to share) and it's high quality for what it does play, so it'll be nice for my hi-fi system if I can get anything on it, but the Sansa Fuze is smaller and more convenient as a portable player and the Pono's going back in the wooden box. Frankly, it feels like it was pushed out half-baked, it's problematic if you don't own a modern Mac, and the imperceptible improvements in audio mean it's definitely not worth the money over what you already own. But that's why you read this blog: I just spent $400 so you don't have to.

Thursday, November 20, 2014

Google's not the default ... yahoo?

Mozilla announced today that they are no longer using Google as the search engine default, changing the agreement that's been in place since 2004, and switching to Bing Yahoo!. I've observed on this blog the conflict of interest that Mozilla has, receiving nearly 85% of their income from what is now their largest market competitor (Google, of course, offering Chrome), so this move really only makes sense. Google will still be available as an option, and you can make it your default like it was before, just not the default default. Erm, by default. In return, Mozilla gets the payola and a guarantee that Yahoo! will honour the Do-Not-Track header over their five year deal; we don't know how much payola, but Google paid Mozilla somewhere north of a $100 million a year, so we must assume it's in a similar ballpark to keep them solvent.

(Speaking of Bing, I've switched from Google Maps to Bing Maps. It's much faster because it's prerendered like Google Maps used to be. Also, in the not-so-coincidental category, Google's new Inbox service doesn't work on Firefox.)

This change is going down in December, probably for Fx35, but it's not clear if this will land on the 31ESR branch. That said, I have no good reason not to honour the change whether it lands on 31 or (from our perspective) 38; I don't get paid by either one of them and they don't care whether we use one or the other, so I've got no dog in this fight. If you don't like this, set your default appropriately. As always, if you want to donate, the best way is to click on the ads on this very blog and let Google pay me on your behalf.

Thursday, April 3, 2014

And now for something completely different: Brendan Eich, and FirefoxOS review for Power Mac users

I've been writing up my FirefoxOS review for this blog/audience, but the flap over Brendan Eich (briefly) as Mozilla CEO eventually came to a crashing halt today with his resignation, not only from the CEO post but from the board and the entire organization. Besides a few private inquiries I got about TenFourFox's use of Mozilla technologies, this news sort of overshadows the entire thing. So here goes. If you want to skip this part, scroll down to the review.

UPDATE: In his own words, leaving Mozilla.

We have many users across the entire spectrum on gay marriage. (That's an important point I'm going to come back to.) This blog is apolitical -- I am intentionally expressing no personal viewpoint on this subject, because it's irrelevant. My use of Mozilla and Gecko, and my actions as a Mozilla contributor and security board member, is because I believe it to be the most community-driven engine, the most standards-friendly engine, and the most open engine. It's not based on support or opposition to the views of any one person in Mozilla, even the CTO (when he was the CTO) or the CEO (when he was the CEO).

For those who don't know the history yet, California (I live in Southern California) qualified Proposition 8 for the ballot in 2008, which stated that the following text, almost in its entirety, be added to the state Constitution: "Only marriage between a man and a woman is valid or recognized in California." This was against a context of several long court battles going back for at least a decade, along with the earlier Proposition 22 in 2000 which passed but did not survive subsequent legal challenge; Prop 8 was designed to address the constitutional issues where Prop 22 had failed. Prop 8 survived to reach a vote and passed, 52.24% in favour (see the Wikipedia map for breakdown by county), and was immediately challenged in court. The California Supreme Court upheld it in 2009, but the United States District Court for the Northern District of California overturned it in 2010, affirmed by the Ninth Circuit Court of Appeals. In 2013, the U.S. Supreme Court denied legal standing to those attempting to defend it, technically overturning the Ninth Court, but leaving the original ruling by the District Court intact. Gay marriage has been legal again in California since 28 June 2013.

California also has a law requiring disclosure of certain personal information of individuals who donate $100 or more in support of or opposition to a ballot measure. This information is public, and is downloadable from the California Secretary of State. Among other groups and news outlets, the Los Angeles Times publicized the donor list for Proposition 8 shortly after the measure passed, making it searchable; soon the entire donor list was widely circulating as boycott targets.

One of those names was one Brendan Eich, of Mozilla, who had donated $1,000. Eich started at Silicon Graphics, where he worked on IRIX, and eventually made his way to Netscape Communications in 1995 where he became the inventor of JavaScript (for Netscape Navigator). After America Online bought out Netscape in 1998 he helped to spin it out as Mozilla, which later became independent, and where he remained until now as the CTO since 2005. Eich's contribution was public record for some time, but did not come to light until 2012 when it was rediscovered. Many of Eich's coworkers, including some of his closest, were shocked and dismayed. However, virtually everyone, even his detractors, agreed that he had never made his views public at work and had left his personal feelings at the door. Such was the background when he was made CEO by the Mozilla board, apparently against the wishes of three board members who later resigned, preferring an external candidate. The reaction was swift, including at least two high-profile boycotts, an employee request for him to resign, and many prolonged flamefests in every corner of the Internet. Eich was repeatedly asked to recant his views and, most recently given an opportunity in an interview with the Guardian, he did not.

Today he did step down, apparently for good, not even returning to his previous position as CTO; it seems his days at Mozilla are done. It's not clear where he's going next.

Free speech in the United States is heavily protected, possibly to a point that our readers from other countries will find absurd, but it is and has been for decades. However, those protections extend to preventing government from abridging those rights; private actors are not so enjoined. One interpretation is that this sad series of events is the system working exactly as designed: Eich had a right to have those views and express them, and those opposed to those views had a right to express their opposition and their displeasure with his employer. That is, essentially, exactly what happened -- he has a right to free speech, but not to be absolved of the consequences, which in this case was likely a "fall on your sword" resignation.

I agree with this principle, but only up to a point. There are clearly certain views that are now so far out of the mainstream that no one will tolerate them in a high profile position anywhere. You may still get to be a racist, or sexist, or express your dismay over miscegenation, in certain parochial environs but at large the vast majority of Americans do indeed reject these views as antiquated, wrong and damaging. Certainly any CEO as high-profile as this would expect to be hounded out for holding such opinions today. However, generational change happens generationally. We did not expect many of the most ardent racists to reject their views; some may have moderated them, and some made public apologies, but many went to their graves with the same beliefs and after racial integration laws and other marked civil rights changes it was their children who grew up in a different world. Gay marriage has not reached that point, and is qualitatively different in that at least a large portion of several religious traditions continues to regard it as immoral. As recently as 2010, only 44% of U.S. citizens supported it; President Obama himself did not reverse his previous statement on gay marriage until 2012. As of 2013, a slim majority supports it, which means almost half of the country still does not or is undecided.

Opposition to gay marriage, despite people's feelings and protestations, is still a mainstream view in the United States (to borrow Lt. Gov. Gavin Newsom's infamous phrase, "whether you like it or not"). It is a mainstream view that is likely to erode bit by bit because of recent Supreme Court rulings on the federal Defense of Marriage Act, which struck it down and will likely be a precedent to overturn laws and constitutional amendments against gay marriage in those states that already have them, and the children of people today who are against gay marriage will grow up in that world instead where it is legal and in many places accepted as normal. But this is generational change. Until then, a significant proportion of Americans hold these views, and many will hold them until the end. In fact, if there were indeed a religious motivation, would we expect differently? More to the point, is anyone with a sincerely held moral objection to gay marriage a "homophobe," even if they accept the legality of gay marriage as reasonable or at least unopposable?

It is highly corrosive to society to exclude or relentlessly ostracise those people whose views were thoroughly acceptable just a short while ago -- it cuts out large swathes of people while accomplishing nothing practically, especially now that the legal argument against gay marriage has been made all but void by the Supreme Court, and acts as a chilling effect on free discourse. There is no honour in establishing a blacklist even if you are on the right side of history. Ah, you say, but Eich's actions are beyond simply expressing a view; he acted willfully with this campaign contribution (and arguably others) to restrict the rights of gays. To this assertion I say you'd better be careful. The U.S. Supreme Court has repeatedly ruled that campaign contributions are indeed a form of free speech like any other, a view doubled down upon just today by McCutcheon v FEC. Like it or loathe it, this was his part of expressing his view in the democratic process just as you or I get to do, and if you don't like this ruling then you should remember it was also this same Supreme Court that overturned DOMA. Live by the sword, die by the sword.

I've had my disagreements with Eich as a community member, but they always have been resolved amicably even when things didn't go my way, and while my interactions with him have always been of a purely professional nature he was always professional. In the end this whole sad affair might be perceived as decisively striking a blow for gay rights, but no one really won here. Certainly not Eich -- where will he go now? Even if he had returned as CTO, who knows if this would have blown over this time? He'll always be "that guy," and someone will always want his head; some posts don't believe he's fit anymore for any job in the tech community. Definitely not Mozilla -- they should have foreseen this and predicted how bad a message this would send to their community and employees and never made him CEO in the first place; now one of their biggest carriers of institutional memory and technical knowledge is under a cloud and will likely never be a meaningful contributor to Mozilla again. This was bad business, plain and simple. Their ill-advised move making him CEO looked tone-deaf; now they look diffident as well. They'll suffer the public relations ramifications of this whole story for years.

But proponents of gay marriage have also lost. A vigourous mob took a man who by all accounts never brought his beliefs to work and who embodied the Open Internet principles on which Mozilla is still grounded, and hounded him out of a job. (Yes, I know he "resigned." Everyone in that position "resigns." Many are told to.) This makes martyrs out of whole cloth and hardens the viewpoints of the people you need to accomplish your goal. It represents the movement badly, and it sets back the generational change that is desired.

Adlai Stevenson once observed that a free society is one where it is safe to be unpopular. If you believe this sort of mob justice is acceptable, pray it never sets its sights on you.

Done with that topic. Now that some of you have stopped reading in fury, let's talk about Firefox OS and the Geeksphone Revolution Revulsion. In this post-PC age, Mozilla has virtually no presence on mobile devices and tablets, and even though there is Firefox Android it's large and unwieldy and hardly used. So Mozilla has focused on the feature-phone market to bring low-spec devices that may not run Android well into smartphone territory. That focus brought us FirefoxOS.

FirefoxOS has direct benefit to us in TenFourFox-land because it is written for (what are now) low-spec phones somewhat straddling the gap between feature phones and smartphones. Happily, these phones have similar specifications to our aging Power Macs, and since the rendering is all cross-platform code, we can reap these benefits on our own hardware. But let's say that you're tired of the Google-Apple binary in smartphones (Windows Phone? really?). You don't trust any of them, not even the new and sexy Microsoft, and you're tired of having to void your warranty to run something else. Ostensibly, at least, you have a third choice and this is it.

My previous review of the Revolution Revulsion was singularly disenchanted with the poky Atom CPU, the crummy screen and the plasticky feel. Most importantly I was really p*ssed off that it came with Android, and AOSP Android 4.2 at that, not the Firefox OS phone I had ordered despite Geeksphone's advertisements to the contrary. Those criticisms still stand.

Fortunately, no thanks to Geeksphone, I discovered where you install it. In Settings, you can select another operating system, and Firefox OS is one of them. It does not dual boot -- this will flash your phone. It will automatically download a build of FirefoxOS from Geeksphone's servers and reboot:

And here we are at the main screen of what appear to be a completely vanilla install:
FirefoxOS distinguishes itself with its particular brand of "apps" which can be hybrid offline or online, but 100% written in HTML5. This isn't as bad as it sounds considering how functional HTML5 has become. Even things like the dialer are HTML5, interfacing through privileged DOM objects with the phone hardware. A number of them come with the default install, but you can delete these freely. If we swipe to the right side, taking a screenshot (Power-Home), we see the rest of the built-in apps:
These are very basic, but functional (except for Mail, which for some reason I could not persuade to work with Gmail). Dialer, SMS, browser, phone book, calendar, music, it's all there. The camera is similarly basic, but here the Revulsion's hardware lets it down. The camera's low light performance is slow,
and the flash white-balances poorly, which ought to be correctable in software. I'm not sure if Geeksphone or Mozilla is to blame here.
The HTML5 apps included with the machine span the gamut; here are the Social ones. (Notice the Spanish labeling.)
More are available in the marketplace, like my current favourite timewaster, 2048:
Happily, notifications and control strip operations work pretty much like most other phones do.
However, Android users such as myself will keep trying to hit the back button, and this doesn't work -- you go "home" and pick other apps. iOS users won't have any problem.

Bluetooth pairing was a little wacky with my G5. It's better if you initiate pairing from the Mac -- if you try to do this from the Geeksphone, then the pairing dance gets a little wild and they try to pair at different intervals and it becomes messy. Once it's done, though, it works fine and transfers files and pictures. You can even queue Bluetooth transmissions up into a big all-at-once blob, which is something my Android Nexus 5 does not do well.

I am also delighted to note that the SD card is fully accessible over USB, so you can dump files and music from your Power Mac right on it. I wish Nexus phones would support this again.

The phone identifies itself as Firefox 28, but gets updates from Geeksphone, not Mozilla.

I haven't yet received an OTA update, so I don't know how well that works. By the way, you should consider the switch to FirefoxOS practically one-way. You can go back to Android, but there is no installer and you will have to reflash the device. But Android is so lousy on this I don't know why anyone would want to.

I don't think FirefoxOS could be my regular phone, at least not yet. I dithered over swapping in my 3G SIM and seeing how long I could put up with it, but decided not to -- I still have a lot of Android apps I like, though I suppose I could run them on a tablet and use a Firefox phone besides, and my work depends on me being accessible at all times and I'm not 100% convinced of that level of reliability with FxOS yet. The biggest problem is, of course, this particular phone: it sucks, even though it sucks a lot less in FirefoxOS than it does in AOSP Android. That does bode well for Mozilla, and a very inexpensive phone running FxOS should be a lot more pleasant than Android on the same hardware plus a lot less restrictive. But I'm not really in that market -- I like high-end hardware, and FxOS is not compelling on that, or at least not on the choices we have now short of buying another Nexus 5 and trying to flash it.

Those of you who are in that market, though, should consider FirefoxOS to be very serviceable. I'd look at another handset than this one, and I wouldn't pay a lot. But if I had to, I think I could use it and adapt to it. It's going to take something better than that to wrest established smartphone users away like me, but for people upgrading to a smartphone from a feature phone, Mozilla has a chance with those people and they might have a chance with you. And being Power Mac friendly, or at least not Power Mac hostile, is a big plus. If Mozilla finds a better hardware partner, I myself would strongly think about buying another Firefox OS device and giving it another shot. Let's hope and see, because I don't want just two tech companies in the mobile space -- and Mozilla needs all the help it can get to stay relevant.

A polite request: no comments about Brendan Eich -- I will delete them, even the ones that agree with this view. I don't have time to moderate a flame war. This post is the only statement I will make on that topic.

Wednesday, May 15, 2013

Mozilla shoots us in the stomach

Bang (previously, previously).

So I'm pretty displeased about this, and once the SPARC and MIPS consumers find out that their respective JavaScript methodjit compiler ports no longer work either, they, too, will be displeased. And SeaMonkeyPPC guys, methodjit was sure nice while it lasted, yes? (You'll lose it in the equivalent for Firefox 23.) But if we were beloved by Mountain View, we wouldn't be a tier-3 port, would we?

However, since I'm a physician by training and medical metaphors simply flow from my fingertips, severe traumatic stomach wounds can be survived with surgery. (See how well I pulled that together? My kid sister is a trauma surgeon. You should only panic if I say that Mozilla shot us in the head.) And I'm trying to operate on this patient as quickly as I can between, you know, having an actual day job in a nearly totally dissimilar field.

Some of the JavaScript team at Mozilla are suggesting that we try implementing the Baseline compiler first, which seems a little strange, since Baseline came on board after Ion. The way it's supposed to work is that Baseline builds a really simple unoptimized code stream -- no type inference or other kinds of "expensive" optimization -- and after a certain number of runs, then big bad Ion comes on and emits superior code, and that runs instead. In fairness, this seems to work as a one-two punch better than methodjit, so I'm not unhappy about the end result, just the fact that Mozilla has really boxed me in here. Implementing Baseline first does have the advantage that there is some common code, I can pull Ion up in stages, and it would be better than the interpreter (but that's like saying rotten fish for dinner is better than nothing for dinner). And Baseline is easier on the processor to compile code, similar to the way TraceMonkey worked, so really slow systems like our G3 users will notice that latency is less even if the code is not as well optimized. But our benchmarks may take it on the chin, and like Mozilla would agree, I don't like shipping regressions.

I'm still waiting for my JS contacts to explain in more detail what's needed to bring Baseline up. The problem is that there's no fully functional Baseline in 22, and there is no point in building 23 -- we want 24 because we want to move to the next ESR at (almost) any cost. So I'm going to hold our stable users on 17 as long as possible. 22 is going to come out, the last version where methodjit was relatively unmolested, and I will start on that port this weekend now that beta 1 is available so I can still take some time off (which I will spend dreaming of throwing darts at Mozilla's corporate office). That, and putative 17.0.7, will still come out on time as usual.

Currently Ion is to the point where it builds, but does not link -- I'm still missing some stuff which I am implementing piece by piece (not yet to phase 2). When 24 hits Aurora, then I'm going to try to get Baseline running first assuming Mozilla isn't blowing smoke up my tailpipe and run numbers. I figure with the work I've already done, getting Baseline to pass tests is going to be at least a full cycle, so there will be no Aurora for you to play with unless there is a major breakthrough (putative 17.0.8 will be released, though, and if there is a major security issue I will put out a bridge 22 release). If I'm lucky, there will be a 24 beta for you in the beta timeframe prior to 24.0 final. Play with it, see if the expected regression is still worth shipping, and Chris T and our localizers can start work with that. If people judge it acceptable, we issue 24.0 on the unstable branch and 17.0.9 on the stable branch to have one more shakedown for bugs, and move stable branch over with 24.0.1/17.0.10, and 17 support ends (I hope Tenfourbird is able to jump to 24 with us -- I would love to see that project continue). If the benchmark regression is not acceptable, we'll just have to hope there's enough time left on 17 to get Ion ready.

This sucks.

Saturday, April 27, 2013

A scrollbar too far (or, why Apple can't kill a Snow Leopard)

One of my perpetual sources of anxiety is whether when Mozilla will drop support for 10.6 Snow Leopard. We've done pretty well keeping 10.4 and 10.5 compatible code in our widget library, and it looks like the code landing for Australis (the new "look" for Firefox) will be compatible with only moderate tweaking at most so far. Because Snow Leopard is essentially a tuned 10.5 and has relatively few UI-related changes, our now fairly streamlined widget library code functions quite well, considering, on all three operating systems (essentially forward-porting the 10.4-specific stuff from 3.6 and the 10.5-specific stuff from 16, for those weirdos in the audience running TenFourFox on Rosetta in 10.6). There haven't been substantial changes to our widget patches since 19, and even then only for the compiler update.

But then of course there's 10.7 Lion, Steve Jobs' Operation Market Garden, where scrolling was screwed and Rosetta was removed and Java was jettisoned (wait, that's a good thing) and scrollbars were iOSified and Save As was deprecated and you can't tell if an application has quit or not. And like 10.6 left behind an entire generation of Macs -- every Power Mac ever made -- 10.7 left behind every 32-bit Intel Mac, and 10.8 won't even run on those 64-bit Intel Macs that can't boot a 64-bit kernel, including my 2007 Core 2 Duo Mac mini which I use for taxes and Android stuff. 10.8 does smoothe out some of the rough edges of 10.7 but doubles down on them in other respects, and why bother downupgrading to 10.7 if I can't upgrade to 10.8 as quickly as possible thereafter? I could boot 10.7 on my mini, but then I lose all the features I need from 10.6, I can't upgrade to 10.8, and I have no apps that demand either one. So 10.6 stays.

In that context, then, I suppose it's not surprising that Mozilla (and probably Chrome as well) has a problem: 43% of their users are on 10.6, an OS that Apple is supporting pretty much in name only right now and will almost certainly cease to after 10.9 emerges (expect word on that from the incredibly oversubscribed WWDC). And why is this? Well, look at the other two numbers: while 10.8 is growing, 10.7 is at 30% and dropping. I can't be the only one who made the calculation that it's better to stay on 10.6 if you can't go to 10.8, and there are still lots of 10.6-only machines in use that really aren't that old. Since Apple isn't maintaining Safari anymore for 10.6, it's alternative browsers ahoy.

Unlike previously premature attempts to kill off platform support on Mozilla's part (ahem), there's a big operations problem brewing here. Apple is obsoleting hardware faster and faster, and Mozilla can't buy more 10.6 or 10.7-capable systems because Apple won't make them. (Used hardware is not generally acceptable for the types of testing they need to do; their Mac mini build farms work very hard.) They might be able to build on a later version of OS X (but not for much longer?), but they wouldn't be able to test how well it works on earlier ones. So they're going to repurpose the 10.7 test systems for 10.6, since it continues to be the majority of Firefox's OS X user base, and make 10.6 and 10.8 the major test platforms until Apple finally has a developer beta of 10.9.

All this is good news for us, of course. On the dark day when Mozilla makes 10.7 the supported minimum, all supported Macs will run a 64-bit build, have hardware acceleration, and use the new UI and related libraries -- none of which is true for us (we still use some Carbon code, limiting us to 32-bit even on G5, we don't have hardware acceleration, and our scrollbars are actually visible and scroll in the correct direction). At minimum we would have so many changes to pull forward that we would almost certainly have to split off separate widget and theme subsystems, and merging work would increase significantly if we could get it to function at all. But with almost half their users on 10.6, even considering that the number is slowly dropping, I'm now not anticipating this will occur until at least the next ESR and the chances of a working TenFourFox 31 have just increased big time.

Tuesday, April 23, 2013

FirefoxOS dev phones sell out

By which I mean they're out of phones for sale on the very first day, and I blame you lot for why I can't buy a Peak Developer Edition. The specs are modest, but the price is eminently reasonable. Last night at 10:30pm the store was down for maintenance, I get up at 5:45am today to get one, and bam.

I'm a longtime Android user, driven to the Nexus One when Apple dropped 10.4 support within the iOS 4 timeframe, and while I don't love it I certainly don't hate it. My Galaxy Nexus is a solid device. Still, when I got to play with a Palm pre 2 (thanks, Ed!) for a period of time it was a delightful machine, and I'm hoping FirefoxOS recaptures that ease of development and feeling of openness that webOS had. Bugs are to be expected in early dev releases like this, and a friend of mine who put a nightly on a castoff phone a couple months back reported it didn't even do cut and paste (!), but I expect it has now developed to the point where you can dogfood it and I certainly hope Mozilla is. If FirefoxOS launches well, it would do much to preserve their relevance and a freer alternative mobile platform in a post-PC era.

Wednesday, April 3, 2013

Blink, there's a new HTML rendering engine

The Web is all abuzz about Blink, Google's fork of WebKit, for use in Chromium and Google Chrome (and, apparently, Opera as well, since it will track Chromium).

I've already said my piece on WebKit, but Blink significantly changes that dynamic. In fact, Blink is likely to completely fragment what would have been a cold WebKit-only future because it is almost certain to evolve and implement new features faster than WebKit will, and exported to everywhere that Google code runs (Android, too). And, well, that's good news in a sense because it avoids one kind of perilous future, but it's bad in another because there won't be much of a brake on Google implementing features in Blink to make Google properties run better or even exclusively in it. Remember, that's the whole reason they made Chrome in the first place, and Microsoft isn't the only one that "embraces and extends."

Maybe it'll be Blink that eats the Web, not WebKit after all.

Friday, February 22, 2013

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.

Wednesday, February 13, 2013

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.