Friday, February 5, 2016

Imagine there's no Intel transition ...

... and with a 12-core POWER8 workstation, it's easy if you try. Reported to me by a user is the Raptor Engineering Talos Secure Workstation, the first POWER workstation I've seen in years since the last of the PowerPC Intellistations. You can sign up for preorders so they know you're interested. (I did, of course. Seriously. In fact, I'm actually considering buying two, one as a workstation and the second as a new home server.) Since it's an ATX board, you can just stick it in any case you like with whatever power supply and options you want and configure to taste.

Before you start hyperventilating over the $3100 estimated price (which includes the entry-level 8-core CPU), remember that the Quad G5, probably the last major RISC workstation, cost $3300 new and this monster would drive it into the ground. Plus, at "only" 130 watts TDP, it certainly won't run anywhere near as hot as the G5 did either. Likely it will run some sort of Linux, though I can't imagine with its open architecture that the *BSDs wouldn't be on it like a toupee on William Shatner. Let's hope they get enough interest to produce a few, because I'd love to have an excuse to buy one and I don't need much of an excuse.

Friday, January 22, 2016

38.6.0 available

TenFourFox 38.6.0 is available for testing (downloads, hashes, release notes). I'm sorry it's been so quiet around here; I'm in the middle of a backbreaking Master's course, my last one before I'm finally done with the lousy thing, and I haven't had any time to start on 45 so far. 38.6 does have some other fixes in it, though: I think I found the last place where bookmark backups were being mistakenly saved in LZ4 based on Chris Trusch's report, and the problematic fonts on the iCloud login page are now blacklisted, so you should be able to login again. I can't do much more testing than that, however, since I don't use iCloud personally, so other lapses in font functionality will require the font URL and I'll add them to the blacklist in 38.7. The browser will go live Monday Pacific time as usual. (The temporary workaround is to set gfx.downloadable_fonts.enabled to false, and switch the setting back when you don't need it anymore.)

Speaking of, downloadable fonts were exactly the same problem on the Sun Ultra-3 laptop I've been refurbishing; Oracle still provides a free Solaris 10 build of 38ESR, but it crashes on web fonts for reasons I have yet to diagnose, so I just have them turned off. Yes, it really is a SPARC laptop, a rebranded Tadpole Viper, and I think the fastest one ever made in this form factor (a 1.2GHz UltraSPARC IIIi). It's pretty much what I expected the PowerBook G5 would have been -- hot, overthrottled and power-hungry -- but Tadpole actually built the thing and it's not a disaster, relatively speaking. There's no JIT in this Firefox build, the brand new battery gets only 70 minutes of runtime even with the CPU clock-skewed to hell, it stands a very good chance of rendering me sterile and/or medium rare if I actually use it in my lap and it had at least one sudden overtemp shutdown and pooped all over the filesystem, but between Firefox, Star Office and pkgsrc I can actually use it. More on that for laughs in a future post.

It has been pointed out to me that Leopard Webkit has not made an update in over three months, so hopefully Tobias is still doing okay with his port.

Tuesday, December 29, 2015

TenFourFoxBox 1.0

For those of you happily using the TenFourFoxBox beta, it's now time for 1.0 as promised.

TenFourFoxBox 1.0 is mostly a feature and bugfix update. You can update your foxboxes in place without losing information; just save the new foxbox over the old one, keeping the app name the same. Aside from various cosmetic tweaks, this release also fixes a problem with sites that try to enumerate navigator.* properties (Chase Bank being the most notorious), since doing so would barf when it got to navigator.mozApps as we didn't have that component loaded. Interestingly, SeaMonkey had this same problem in bug 1094714, which they solved by effectively importing the entire JavaScript webapps framework. That wasn't acceptable here where the whole point is to strip the browser down, so I got around this problem by creating a dummy stub XPCOM component to replace it and splicing that in. Much more lightweight!

In addition, a number of you apparently rename your TenFourFox builds to just, so this version will try that filename if the proper machine architecture is not found. If you really can't control for that either, make a copy of the browser as and it will take precedence over any other executable (but remember to keep that copy up to date!).

Finally, there were also several requests for allowing URLs to be sent back or at least copied for the main browser's benefit. I'm weighing my options on how to push the URL through (Launch Services or otherwise), but you can at least now go to the Box menu and copy the current location URL to the clipboard, or right-click any link to do the same, which you can then paste into your browser of choice. Localization is still not yet supported because we're not yet to a string-freeze point, but we're getting close.

Remember to stop all foxboxes before you upgrade them, and make sure TenFourFox is still running before you start them back up if you want to have the main browser running parallel. Developers, look at the Makefile in the Things To Try: For Developers folder for how to automate foxbox creation and upgrades from the command line.

As of this release, TenFourFoxBox has an official home page and download site and you can grab 1.0 from there. Assuming no major issues by the end of this week, we'll start publicly rolling it out, and then I'll start the arduous trek towards TenFourFox 45. Meanwhile, for 38.6, there will be some updates to the font blacklist but so far no major bugs yet.

Saturday, December 12, 2015

38.5.0 available, and maybe 45 as the swan song, in not too long

TenFourFox 38.5.0 is now available for testing (download, hashes, release notes). Remember to quit any foxboxes you have open before you update the browser, and start the browser before you start any foxboxes back up if you want to have the browser and foxboxes running simultaneously (the Dock gets a little confused otherwise). This version backs out the last of the debugging code from issue 308 (which also yields a small improvement to memory and speed), works around issue 307 to always dump .json bookmarks (now with the correct extension), and fixes the application menu in foxboxes and certain add-ons by importing the patch from Mozilla bug 1181977.

This version also enables MP3 audio support by default (we use the minimp3 decoder, which I hacked for our purposes since AudioToolbox in 10.4 does not understand MP3). There are already some known files that don't play in it that do play in QuickTime, so this appears to be a bug in minimp3. If you report MP3 files that don't work, please include the encoder so we have at least a chance at something analysable. If you don't, I'll still accept the report, but I may not do much with it unless it's glaringly obvious what about the file it doesn't like.

With 38.5, Firefox 45, the next ESR, moves out of nightly into aurora. Since Mozilla is only up to the point of doing A/B testing for multi-process Electrolysis in Fx44 beta, it seems unlikely that 45ESR will make Electrolysis mandatory, so that means I would be foolish to not make at least an attempt at porting it. This will require another toolchain upgrade like we did for TenFourFox 19. Fortunately, we do have a working gcc 4.8 in MacPorts and it does build and run 38 successfully without our current gcc 4.6 shim, and I'm working with Sevan Janiyan to get the Tiger pkgsrc gcc 4.9 functional (it seems to need updates to as and ld, since it will parse the source, but currently builds a defective XUL). I'm also looking into using Misty DeMeo's Tigerbrew gcc as an alternative. Either way, after the update for TenFourFoxBox and its official release I'll probably start working on trying to adapt 45ESR, which should give us plenty of time to have a functional beta out by 45.1, assuming it doesn't blow up in my face.

I am, however, going to call 45 the end of source parity, and this time I mean it. I know I've said "the end" lots of times in the past, but besides the fact Electrolysis won't compile as-is on 10.4 (and quite possibly will be a net negative even if it works), and Electrolysis will almost certainly be mandatory by 52ESR now, Mozilla is now importing code written in Rust into Gecko, not just C/C++. Although Rust allegedly supports PowerPC, it is only known to work on Linux (and there isn't a snapshot, rustc or cargo for it even there); it is not known to work, or have a snapshot available, for OS X/ppc, and then there's the matter of llvm on our same platform. Mercifully it does not appear any of the existing Rust code (which is already in the tree) will be required for 45ESR, but it does appear that new Rust code will replace a number of older C/C++ modules by 52ESR once Mozilla works out the build system kinks, making Rust a build requirement. This would be a showstopper for us and any other Tier-3 platform that lacks a Rust compiler (Solaris on SPARC? the remnants of OS/2?). It would also probably signal the end of 10.6 support in the near future, since by default the Rust standard library requires features Snow Leopard doesn't have (though there are ways around it).

Frankly, I'm not going to maintain a completely new compiler for a language I'm not fluent in and its runtime platform on top of a browser and debugger I'm already maintaining singlehandedly when we're already facing two other portkillers (loss of 10.6 support, whenever that comes, and E10S). Assuming this trajectory continues unchanged we will drop source parity after 45ESR, but there will of course still be updates; besides new features we can now release since we're not worried about maintainability against Mozilla source anymore, we'd still get a fair chance to import later updates to the core that were still in C/C++, and we'd be still a very advanced browser for at least a couple years. We'd be better off than Goanna in Pale Moon, anyway, which is still 24.x-era with various patches.

It had to happen for real sooner or later.

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.

Saturday, November 21, 2015

TenFourFoxBox: because it's time to think inside the (fox)box. (a/k/a: we dust off Mozilla Prism for a new generation)

As long as there have been web browsers, there have been people trying to get the web freed up from the browser that confines it, because, you know, the Web wants to be free, or some other similarly aspirational throwaway platitude. These could be robots, or screen scrapers, or aggregating services, or chromeless viewers, but no matter what these browserless browsers are doing, they all tend to specialize in a particular site for any number of reasons usually circulating around business or convenience. This last type, the chromeless viewer, spawned the subcategory of "site specific browsers" that morphed into the "Rich Internet Application" and today infects our phones and tablets in the guise of the "lazy-*ss programmer mobile app."

Power Mac users have only had access to a few tools that could generate site-specific browsers. Until Adobe withdrew support, Adobe AIR could run on PowerPC 10.4+, but it was more for generally Internet-enabled apps and wasn't specifically focused at creating site-specific browsers, though it could, with a little work. Leopard users could use early betas of Fluid before that went Intel-only, and I know a few of you still do. Even Mozilla themselves got into the act with Mark Finkle's WebRunner, which became Mozilla Prism in 2007, languished after a few releases, got moved to Salsita and renamed WebRunner again in 2011, and cancelled there as well around the time of Firefox 5. However, WebRunner née Prism née WebRunner was never available for Power Macs; its required binary components were Intel-only, even though the Mozilla releases could run on 10.4, so that was about it for PowerPC. (Mozilla tried again shortly afterward with Chromeless, but this didn't get off the ground either, and was never intended as a Prism successor in any case. Speaking of, Google Chrome can do something similar, but Chrome was of course never released for Power Macs either because Alphagooglebet are meaniepants.)

There are unique advantages as TenFourFox users to having separate apps that only handle one site at a time. Lots of tabs requires lots of garbage collection, the efficiency of which Mozilla has improved substantially, but is still a big drain on old computers like ours which are always under memory pressure. In addition, currently Firefox and TenFourFox must essentially cooperatively multitask between tabs because JavaScript infamously has run-to-completion semantics, which is why you get the "script too long" dialogue box if the watchdog portion of the browser detects something's pegging it. Since major portions of the browser itself are written in JavaScript, plus all those addons you tart it up with, the browser chrome must also cooperatively multitask with everything else which is why sometimes it temporarily grinds to a halt. I've sunk an incredible amount of time over TenFourFox's existence into our just-in-time JavaScript compiler for PowerPC to reduce this overhead, but that only gets us so far, and the typical scripts on popular websites aren't getting any less complex. Mozilla intends to solve this problem (and others) with multi-process Firefox, also known as Electrolysis, but it won't work without significant effort on 10.4 and I have grave doubts about its ability to perform well on these older computers; for that reason, I've chosen not to support it.

However, generating standalone browser apps for your common sites helps to mitigate both these problems. While each instance of the standalone browser uses more memory than a browser tab, with only one site in it garbage collection is much easier to accomplish (and therefore faster), and the memory is instantly reclaimed when the standalone browser terminates. In fact, on G5 systems with more than 2GB of RAM, it helps you actually use that extra memory more effectively: while TenFourFox is a 32-bit application (being a hybrid of Carbon and Cocoa), you'd be running multiple instances of it, all of which have their own 32-bit address space which can be located in that extra RAM you've got on board. Also, separate browser instances become ... multiple processes. That means they preemptively multitask, like Electrolysis content processes would. They could even be scheduled on a different core on multiprocessor Power Macs. That improves their responsiveness substantially, to say nothing of the fact that the substantially reduced amount of browser chrome has dramatically less overhead. Now, standalone browsers also have disadvantages; they lack a lot of the features of a regular browser, including safety features, and they can be more difficult to navigate in because of the reduced interface. But for many sites those are acceptable tradeoffs.

So, without further ado, let's introduce TenFourFoxBox.

TenFourFoxBox is an application that generates site-specific browsers ("foxboxes") for you, running them in private instances of TenFourFox (a la XULRunner). This has been one of my secret internal projects since I got Amazon Music working properly with TenFourFox, so I wanted to use it as a jukebox without dragging down the rest of the browser, and to help beef up the performance of my online coursework site which has a rather heavy implementation and depends greatly on Google Docs and Box. And now you'll get to play with it as well.

Although TenFourFoxBox borrows some code from Prism/WebRunner, mostly the reduced browser chrome, in actual operation it functions somewhat differently. First, TenFourFoxBox isn't itself written in XUL; it's a "native" OS X application that just happens to generate XUL-based applications. Second, for webapps created with Prism (or its companion tool Refractor), it's Prism itself that actually does the running with its own embedded copy of the XUL framework, not Firefox. With TenFourFoxBox, however, foxboxes you create actually run using the copy of TenFourFox you have installed (and yes, the foxboxes will look for and run the correct version for your architecture), just as separate processes, with their own browser chrome and their own application support and cache directory independent of the main browser. The nice thing about that is when you upgrade TenFourFox, you upgrade the browser core in every foxbox on your system all at once, as well as your main browser, because TenFourFox is your main browser, amirite?

The implementation in TenFourFoxBox is also a little different with respect to how data is stored. Foxboxes are driven essentially as independent XULRunner apps, so they have their own storage separate from the browser. Prism allowed this space to be shared, but I don't think that was a good idea, so not only are all foxboxes independent, but by default they operate effectively in "private browsing" mode and clear out cookies and other site data when they quit. By default they also disable autocomplete, improving both privacy and a little bit of performance; you can, of course, change these settings, and override checks sites might do which could detect you're not actually in a regular browser. I also decided to keep a constant unchanging title (regardless of the website you're viewing) so that you can more easily identify it in Exposé.

So, let's see it in action. Here's Bing Maps, in full 1080p on the quad G5, looking for drone landing sites.

And here's what I originally wrote this for, Amazon Music, playing the more or less official album of International Space Year:

(Stupid Amazon. I already have Flood and Junta!)

So now it's time to get this ready for the masses, and what better way than to have you slavering lot mercilessly bang on it? The following bugs/deficiencies are known:

  • The application menu only has "Quit." This is actually Mozilla bug 1181977, and will be fixed in TenFourFox 38.5, after which all the foxboxes will "fix themselves."
  • Localization isn't supported yet, even if you have a localized TenFourFox; most things will still appear in English. It's certainly possible to do, just non-trivial because of TenFourFoxBox's dual nature (we have to localize both the OS X portion and the XUL code it generates, and then figure out how to juggle multi-lingual resources). I'm not likely to do anything with this until the rest of it is stable enough to freeze strings.
  • Although the browser core they run is shared, individual foxboxes have their own private copies of the foxbox support code and chrome which are independent. Thus, when a new TenFourFoxBox comes out, you will need to manually update each of your foxboxes. You can do this in place and overwrite them; it's just somewhat inconvenient.
  • There are probably browser features missing that you'd like. I'm willing to entertain reasonable requests.

Even the manual is delivered as a foxbox, which makes it easy to test on your system. Download it, try it and post your comments in the comments. TenFourFox 38.4 or higher is required. This is a beta, so treat it accordingly, with the plan to release it for general consumption a week or so after 38.5 comes out.

Let's do a little inside-the-box thinking with an old idea for a new generation, shall we?

Wednesday, November 11, 2015

Two interesting things

(Shout-out to Stories of Apple, which did a very nice piece on TenFourFox. Check out their other fascinating articles on Apple history. And a shout-out to my father, an American veteran, for his service to this country.)

First, from the Google Chrome blog:

Today, we’re announcing the end of Chrome’s support for Windows XP, as well as Windows Vista, and Mac OS X 10.6, 10.7, and 10.8, since these platforms are no longer actively supported by Microsoft and Apple. Starting April 2016, Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

(Recall that Google had already dropped 32-bit Intel Macs with Chrome 39.)

I've long warned on this blog that Firefox dropping 10.6 support will probably really hurt us in TenFourFox-land, since there are major API changes and assumptions about the compiler, as well as the loss of 32-bit support (we are a hybrid Carbon/Cocoa 32-bit application, even on G5 systems). Naturally, we would of course add it back in just like we did when 10.4 and 10.5 support was progressively removed from the tree, but it would greatly hurt long-term maintainability and may force dependencies on certain features Tiger just doesn't have. However, with 45 (the next ESR) now on Nightly with 10.6 support still fully in effect, and with even plans to merely drop 10.6.0-10.6.2 stalling, it doesn't look like that will happen before 45ESR. That at least gives us a chance at one more ESR version assuming Electrolysis isn't mandatory by then.

Now, second. I've never particularly been a big fan of Grüber Alles, but he says something very interesting in his review of the iPad Pro:

According to Geekbench's online results, the iPad Pro is faster in single-core testing than Microsoft's new Surface Pro 4 with a Core-i5 processor. The Core-i7 version of the Surface Pro 4 isn't shipping until December -- that model will almost certainly test faster than the iPad Pro. But that's a $1599 machine with an Intel x86 CPU. The iPad Pro starts at $799 and runs an ARM CPU -- Apple's A9X. There is no more trade-off. You don't have to choose between the performance of x86 and the battery life of ARM.

We've now reached an inflection point. The new MacBook is slower, gets worse battery life, and even its cheapest configuration costs $200 more than the top-of-the-line iPad Pro.

Although it's quite possible this says more about how bad the new MacBook sucks than about how good the iPad Pro is, it really looks like those P.A. Semi folks Apple snapped up a few years back (yes, the people who worked on the PWRficient PA6T, one of the PowerPC CPUs in the running for the post-PowerBook G4 PowerBook) are starting to make serious inroads against x86. POWER remains a monster in the datacenter because it can scale, and, well, it's IBM, but IBM hasn't cared (as much) about performance per watt in that environment for quite some time whereas that matters a great deal in the consumer market, and that's why we never got a PowerBook G5. For years industry pundits said the reason ARM chips were so thrifty with their power usage is that they weren't all that powerful, comparatively speaking. Well, the A9X changes that landscape substantially: now you've got an ARM core that's seriously threatening the low to mid range of Chipzilla's market segment and is highly power efficient, and I can't imagine Intel isn't scared about Apple licensing their design. This blog may be written by an old RISC fetishist -- in this very room I have a PA-RISC, a SuperH, a SPARC, a DEC Alpha, several SGI-MIPS and of course a whole crapload of PowerPC hardware -- but after seeing these surprising benchmark numbers all those old rumours about Apple eventually coming up with an ARM MacBook suddenly don't seem all that far-fetched.

Finally, okay, okay, three things, this Engrish gem from mozilla.governance, emphasis mine:

I’m now writing to you to tell you something that make me puzzled. As I know, Firefox is a free browser which offers users independent web suffering.

We all know it, brother. We all know it. :)