TenFourFox Development

Thursday, March 15, 2018

Stand by for FPR6 Security Parity Release 1 due to the usual turmoil following Pwn2Own, in which the mighty typically fall and this year Firefox did. We track these advisories and always plan to have a patched build of TenFourFox ready and parallel with Mozilla's official chemspill release; I have already backported the patch and tested it internally.

The bug in question would require a TenFourFox-specific exploit to be useful, but is definitely exploitable, and fortunately was easily repaired. The G5 will chug overnight and have builds tomorrow and heat the rear of the house all at the same time.

Saturday, March 10, 2018

TenFourFox Feature Parity Release 6 is now available for testing (downloads, hashes, release notes). Other than finishing the security patches and adding a couple more entries to the basic adblock, there are no other changes in this release. Assuming no issues, it will become live Monday evening Pacific time as usual.

The backend for the main download page at Floodgap has been altered such that the Downloader is now only offered to browsers that do not support TLS 1.2 (this is detected by checking for a particular JavaScript math function Math.hypot, the presence of which I discovered roughly correlates with TLS 1.2 support in Google Chrome, Microsoft Edge, Safari and Firefox/TenFourFox). This is to save bandwidth on our main server since those browsers are perfectly capable of downloading directly from SourceForge and don't need the Downloader to help them. This is also true of Leopard WebKit, assuming the Security framework update is also installed.

For FPR7, I have already exposed basic adblock in the TenFourFox preferences pane, and am looking at some efficiency updates as well as updates to the supported TLS ciphers and hopefully date pickers if there is still time. Also, the limited profiling tools I have at my disposal suggest that some of the browser's occasional choppiness is at least partially associated with improperly scheduled garbage collection slices. I'm experimenting with retuning the runtime environment to see if we can stave off some types of collection to preserve CPU cycles and not bloat peak memory usage too much. So far, 24 hours into testing with some guesswork numbers, it doesn't seem to be exploding. More on that later.

Saturday, March 3, 2018

As I watch Law and Order reruns on my business trip, first, a couple followups. The big note is that it looks like Intel and some ARM cores aren't the only ones vulnerable to Meltdown; Raptor Computer Systems confirms that Meltdown affects at least POWER7 through POWER9 as well, and the Talos II has already been patched. It's not clear if this is true for POWER4 (which would include the G5) through POWER6 as these processor generations have substantial microarchitectural differences. However, it doesn't change anything for the G3 and 7400, since because they appear to be immune to Spectre-type attacks means they must also be immune to Meltdown. As a practical matter, though, unless you're running an iffy program locally there is no known JavaScript vector that successfully works to exploit Spectre (let alone Meltdown) on Power Macs, even on the 7450 and G5 which are known to be vulnerable to Spectre.

Also, the TenFourFox Downloader is now live. After only a few days up with no other promotion, it's pulling down about 200 downloads a day. I note that some small number are current TenFourFox users, which isn't really what this is intended for: the Downloader is unavoidably -- and in this case, also unnecessarily -- less secure, and just consumes bandwidth on Floodgap downloading a tool to download something the browser can just download directly. If you're using TenFourFox already (at least 38 or later), please just download upgrades with the browser itself. In addition, some are Intel Mac users on 10.6 and earlier, which the Downloader intentionally won't grab for because we don't support them. Nevertheless, the Downloader is clearly accomplishing its goal, which is important given that many websites won't be accessible to Power Mac users anymore without it, so it will be a permanent addition to the site.

Anyway, let's talk about Power Macs and radios. I'm always fond of giving my beloved old Macs new things to do, so here's something you can think about for that little G4 Mac mini you tossed in the closet. Our 2,400 square foot house has a rather curious floor plan: it's a typical California single-floor ranch but configured as a highly elongated L-shape along the bottom and right legs of the property's quadrilateral. If I set something playing somewhere in the back of the house you probably won't hear it very well even just a couple rooms away. The usual solution is to buy something like a Sonos, which are convenient and easy to operate, but streaming devices like that can have synchronization issues and they are definitely not cheap.

But there's another solution: set up a house FM transmitter. With a little spare time and the cost of the transmitter (mine cost $125), you can devise a scheme that turns any FM radio inside your house into a remote speaker with decent audio quality. Larger and better engineered than those cheapo little FM transmitters you might use in a car, the additional power allows the signal to travel through walls and with careful calibration can cover even a relatively large property. Best of all, adding additional drops is just the cost of another radio (instead of an expensive dedicated receiver), and because it's broadcast everything is in perfect sync. If your phone has an FM radio you can even listen to your home transmitter on that!

There are some downsides to this approach, of course. One minor downside is because it's broadcast, your neighbours could tune in (don't play your potentially embarrassing, uh, "home movie" audio soundtracks this way). Another minor downside is that the audio quality is decent but not perfect. The transmitter is in your house, so interference is likely to be less, but things as simple as intermittently energized electrical circuits, bad antenna positioning, etc., can all make reception sometimes maddeningly unpredictable. If you're an uncompromising audiophile, or you need more than two-channel audio, you're just going to have to get a dedicated streaming system.

The big one, though, is that you are now transmitting on a legally regulated audio band without a license. The US Federal Communications Commission has provisions under Part 15 for unlicensed AM/FM transmission which limit your signal to an effective distance of just 200 feet. There are more specific regulations about radiated signal strength, but the rule of thumb I use is that if you can detect a usable signal at your property line you are probably already in violation (and you can bet I took a lot of samples when I was setting this up). The FCC doesn't generally drive around residential neighbourhoods with a radio detector van and no one's going to track down a signal no one but you can hear, but if your signal leaks off your property it only takes one neighbourhood busybody with a scanner and nothing better to do to complain and initiate an investigation. Worse, if you transmit on the same frequency as an actually licensed local station and meaningfully interfere with their signal, and they detect it (and if it's meaningful interference, I guarantee you they will sooner or later), you're in serious trouble. The higher the rated wattage for your transmitter, the greater the risk you run of getting busted, especially if you are in a densely populated area. If you ever get a notice of violation, take it seriously, take your transmitter completely offline immediately, and make sure you tell the FCC in writing you turned it off. Don't turn it back on again until you're sure you're in compliance or you may be looking at a fine of up to $75,000. If you're not in the United States, you'd better know what the law is there too.

So let's assume you're confident you're in (or can be in) compliance with your new transmitter, which you can be easily with some reasonable precautions I'll discuss in a moment. You could just plug the transmitter into a dedicated playback device, and some people do just that, but by connecting the transmitter to a handy computer you can do so many other useful things. So I plugged it into my Sawtooth G4 file server, which lives approximately in the middle of the house in the dedicated home server room:

There it is, the slim black box with the whip antenna coming off the top sandwiched between the FireWire hub (a very, very useful device and much more reliable than multiple FireWire controllers) and the plastic strut the power strip is mounted on. This is the Whole House FM Transmitter 3.0 "WHFT3" which can be powered off USB or batteries (portable!), has mic and line-level inputs (though in this application only line input is connected), includes both rubber duck and whip antennas (a note about this presently) and retails for about $125. Amazon carries it too (I don't get a piece of any sales, I'm just a satisfied customer). It can crank up to around 300 milliwatts, which may not seem like much to the uninitiated, but easily covers the 100 foot range of my house and is less likely to be picked up by nosy listeners than some of the multi-watt Chinese import RF blowtorches they sell on eBay (for a point of comparison, a typical ham mobile radio emits around 5 watts). It also has relatively little leakage, meaning it is unlikely to be a source of detectable RF interference when properly tuned.

By doing it this way, the G4, which is ordinarily just acting as an FTP and AFP server, now plays music from playlists and the audio is broadcast over the FM transmitter. How you decide to do this is where the little bit of work comes in, but I can well imagine just having MacAmp Lite X or Audion running on it and you can change what's playing over Screen Sharing or VNC. In my case, I wrote up a daemon to manage playlists and a command-line client to manipulate it. 10.5+ offers a built-in tool called afplay to play audio files from the command line, or you can use this command line playback tool for 10.2 through 10.4. The radio daemon uses this tool (the G4 server runs Tiger) to play each file in the selected folder in order. I'll leave writing such a thing to the reader since my radio daemon has some dependencies on the way my network is configured, but it's not very complex to devise in general.

Either way works fine, but you also need to make sure that the device has appropriate signal strength and input levels. The WHFT3 allows you to independently adjust how much strength it transmits with a simple control on the side; you can also adjust the relative levels for the mic and line input if you are using both. (There is a sorta secret high-level transmission mode you can enable which I strongly recommend you do not: you will almost certainly be out of FCC compliance if you do. Mine didn't need this.) You should set this only as high as necessary to get good reception where you need it, which brings us to making sure the input level is also correct, as the WHFT3 is somewhat more prone to a phenomenon called over-modulation than some other devices. This occurs when the input level is too high and manifests as distortion or clipping but only when audio is actually playing.

To calibrate my system, I first started with a silent signal. Since the frequency I chose had no receivable FM station in my region of greater Los Angeles (and believe me, finding a clear spot on the FM dial is tough in the Los Angeles area), I knew that I would only hear static on that frequency. I turned on the transmitter with no input using the "default" rubber duck antenna and went around the house with an FM radio with its antenna fully retracted. When I heard static instead of nothing, I knew I was exceeding the transmission range, which gave me an approximate "worst case" distance for inside the house. I then walked around the property line with the FM radio and its antenna fully extended this time for a "within compliance" test. I only picked up static outside the house, but inside I couldn't get enough range in the kitchen even with the transmitter cranked up all the way, so I ended up switching the rubber duck antenna for the included whip antenna. The whip is not the FCC-approved configuration (you are warned), but got me the additional extra range, and I was able to back down the transmitter strength and still be "neighbour proof" at the property line. This is also important for audio quality since if you have the transmitter power all the way up the WHFT3 tends to introduce additional distortion no matter what your input level is.

Next was to figure out the appropriate input level. I blasted Bucko and Champs Australian Christmas music and backed down the system volume on the G4 until there was no distortion for the entire album (insert your own choice of high volume audio here such as Spice Girls or Anthrax), and checked the new level a few times with a couple other albums until I was satisfied that distortion and overmodulation was at a minimum. Interestingly, while you can AppleScript setting the volume in future, what you get from osascript -e 'set ovol to output volume of (get volume settings)' is in different units than what you feed to osascript -e 'set volume X': the first returns a number from 0-100 with 14 unit steps, but the second expects a number from 1-10 in 0.1 unit steps. The volume on my G4 is reported by AppleScript as "56" but I set that on startup in a launchd startup item with a volume value of 4.0 (i.e., 4 times 14 equals 56). Don't ask me why Apple did it this way.

There were two things left to do. First was to build up a sufficient library of music to play from the file server, which (you may find this hard to believe) really is just a file server and handles things like backups and staging folders, not a media server. There are many tools like the most excellent X Lossless Decoder utility -- still Tiger and PowerPC compatible! -- which will rip your CDs into any format you like. I decided on MP3 since the audio didn't need to be lossless and they were smaller, but most of the discs I cared about were already ripped in lossless format on the G5, so it was more a matter of transcoding them quickly. The author of XLD makes the AltiVec-accelerated LAME encoder he uses available separately, but this didn't work right on 10.4, so I took his patches against LAME 3.100, tweaked them further, restored G3 and 10.4 compatibility, and generated a three-headed binary that selects for G3, G4 and a special optimized version for G5. You can download LAMEVMX here, or get the source code from Github.

On the G5 LAMEVMX just tears through music at around 25x to as much as 30x playback speed, over three times as fast as the non-SIMD version. I stuck the MP3 files on a USB drive and plugged that in the Sawtooth so I didn't have to take up space on its main RAID, and the radio daemon iterates off that.

The second was figuring out some way to use my radios as, well, radios. Yes, you could just tune them to another station and then tune them back, but I was lazy, and when you get an analogue tuner set at that perfect point you really don't want to have to do it again over and over. Moreover, I usually listen to AM radio, not FM. One option is to see if they stream over the Internet, which may even be better quality, though receiving them over the radio eliminates having to have a compatible client and any irregularities with your network. With a little help from an unusual USB device, you can do that too:

This is the Griffin radioSHARK, which is nothing less than a terrestrial radio receiver bolted onto a USB HID. It receives AM and FM and transmits back to the Mac over USB audio or analogue line-level out. How do we hook this up to our Mac radio station? One option is to just connect its audio output directly, but you should have already guessed I'd rather use the digital output over USB. While you can use Griffin's software to tune the radio and play it through (which is even AppleScript-able, at least version 2), it's PowerPC-only and won't run on 10.7+ if you're using an old Intel Mac for this purpose, and I always prefer to do this kind of thing programmatically anyhow.

For the tuner side, enterprising people on the Linux side eventually figured out how to talk to the HID directly and thus tune the radio manually (there are two different protocols for the two versions of the radioSHARK; more on this in a moment). I combined both protocols together and merged it with an earlier but more limited OS X utility, and the result is radioSH, a commandline radio tuner. (You can also set the radioSHARK's fun blue and red LEDs with this tool and use it as a cheapo annunciator device. Read the radioSH page for more on that.) I compiled it for PowerPC and 32-bit Intel, and the binary runs on anything from 10.4 to 10.13 until Apple cuts off 32-bit binary compatibility. The source code is available too.

For USB audio playthru, any USB audio utility will suffice, such as LineIn (free, PowerPC compatible) or SoundSource (not free, not PowerPC compatible), or even QuickTime Player with a New Audio Recording and the radioSHARK's USB audio output as source. Again, I prefer to do this under automatic control, so I wrote a utility using the MTCoreAudio framework to do the playback in the background. (Use this source file and tweak appropriately for your radioSHARK's USB audio endpoint UID.) At this point, getting the G4 radio station to play the radio was as simple as adding code to the radio daemon to tune the radio with radioSH and play the USB audio stream through the main audio output using that background tool when a playlist wasn't active (and to turn off the background streamer when a playlist was running). Fortunately, USB playthru uses very little CPU even on this 450MHz machine.

I mentioned there are two versions of the radioSHARK, white (v1) and black (v2), which have nearly completely different hardware (belied by their completely different HID protocols). The black radioSHARK is very uncommon. I've seen some reports that there are v1 white units with v2 black internals, but of the three white radioSHARKs I own, all of them are detected as v1 devices. This makes a difference because while neither unit tunes AM stations particularly well, the v1 seems to have poorer AM reception and more distortion, and the v2 is less prone to carrier hum. To get the AM stations I listen to more reliably with better quality, I managed to track down a black radioSHARK and stuck it in the attic:

To improve AM reception really all you can do is rotate or reposition the receiver and the attic seemed to get these stations best. A 12-foot USB extension cable routes back to the G4 radio station. The radioSHARK is USB-powered, so that's the only connection I had to run.

To receive the radio on the Quad G5 while I'm working, I connected one of the white radioSHARKs (since it's receiving FM, there wasn't much advantage to trying to find another black unit). I tune it on startup with radioSH to the G4 and listen with LineIn. Note that because it's receiving the radio signal over USB there is a tiny delay and the audio is just a hair out of sync with the "live" analogue radios in the house. If you're mostly an Intel Mac house, you can of course do the same thing with the same device in the same way (on my MacBook Air, I use radioSH to tune and play the audio in QuickTime Player).

For a little silliness I added a "call sign" cron job that uses /usr/bin/say to speak a "station ID" every hour on the hour. The system just mixes it over the radio daemon's audio output, so no other code changes were necessary. There you go, your very own automatic G4 radio station in your very own house. Another great use for your trusty old Power Mac!

Oh, one more followup, this time on Because I Got High Sierra. My mother's Mac mini, originally running Mavericks, somehow got upgraded to High Sierra without her realizing it. The immediate effect was to make Microsoft Word 2011 crash on startup (I migrated her to LibreOffice), but the delayed effect was, on the next reboot (for the point update to 10.13.2), this alarming screen:

The system wouldn't boot! On every startup it would complain that "macOS could not be installed on your computer" and "The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged." Clicking Restart just caused the same message to appear.

After some cussing and checking that the drive was okay in the Recovery partition, the solution was to start in Safe Mode, go to the App Store and force another system update. After about 40 minutes of chugging away, the system grudgingly came up after everything was (apparently) refreshed. Although some people with this error message reported that they could copy the OSInstall.mpkg file from some other partition on their drive, I couldn't find such a file even in the Recovery partition or anywhere else. I suspect the difference is that these people encountered this error immediately after "upgrading" to Because I Got High Sierra, while my mother's computer encountered this after a subsequent update. This problem does not appear to be rare. It doesn't seem to have been due to insufficient disk space or a hardware failure and I can't find anything that she did wrong (other than allowing High Sierra to install in the first place). What would she have done if I hadn't been visiting that weekend, I wonder? On top of all the other stupid stuff in High Sierra, why do I continue to waste my time with this idiocy?

Wednesday, February 21, 2018

TenFourFox Feature Parity Release 6 beta 1 is now available for testing (downloads, release notes, hashes). FPR6 has speculative but high-confidence fixes for freezes on Facebook due to a corner case with our little-endian typed array emulation and occasional crashes with textboxes which seems to be due to a glitch with getting the current CoreGraphics context. The ATSUI font blacklist has been expanded (fixing TurboTax and the Los Angeles Times) and performance has been improved slightly, URL bar handling has been tuned up and is snappier, the AltiVec routine used for YUV conversion and scaling has been tweaked to reduce unaligned loads (cutting three SIMD instructions per pixel), and I've done some manual hinting in JavaScript for when the branch predictor evicts the result. There are several new DOM features which get us a couple extra HTML5 points on benchmarks and fix sites like the Home Depot; finally, there is also one big new feature which is currently not yet exposed in the UI and I'll talk about this in a moment.

Partial work on native date pickers (with eventually time pickers) and support for idle callbacks (allowing better performance and scheduling of JavaScript tasks) is in FPR6, but they're not finished yet and therefore not enabled. The native date-time pickers use the standard NSDatePicker control instead of the XUL-based one in current versions of Firefox. Since we don't have to deal with a Windows or GTK version, we can just use the operating system controls built into Mac OS X and eliminate a lot of date management code by simply relying on the OS implementation; I have a prototype control working but haven't hooked it up to the input field yet (for simplicity, it will act as a OS modal window). Idle callbacks and support for requestIdleCallback exist in the WebIDL but don't connect to anything and there is only a skeleton implementation which does not yet function. The expected timeframe for these is somewhere around FPR7 or FPR8 and I will be working on them up until then; both of these are features I expect to see more use of, and we should support.

Unfortunately, unless you already have TenFourFox, you won't be able to download it: the "TLS apocalypse" has come to Power Macs running OS X. No browser that was previously available for PPC OS X can download TenFourFox now that SourceForge is mandating minimum TLSv1.1 support: Classilla, Safari 4, Safari 5, Camino and Firefox 3.6 all only support TLSv1.0. For that matter, TenFourFox didn't support TLSv1.1 or TLSv1.2 until version 31, when both were enabled (Mozilla added support in Firefox 27), and Safari didn't add support until version 7. The only other browser that supports TLSv1.1 or better on PPC OS X is Leopard WebKit when you also install the updated Security framework, and of course WebKit shells linked against those components, but it doesn't run on Tiger and it is also hosted on SourceForge.

SourceForge, however, is just following along with the general trend of removing TLSv1.0 support (SSLv2 and SSLv3 support have of course long since been deprecated on just about every major site). On February 22 -- tomorrow -- Github will end support for anything prior to TLSv1.2 and certain cryptographic algorithms. (If you are using a Power Mac to develop with a Github project, you'll need to upgrade your git and dependent components. I'm looking at providing those pieces as a way of facilitating development.) As the number of browsers limited to TLSv1.0 (and eventually v1.1) diminishes on the Web, more and more sites will remove support and be inaccessible to Power Macs with the default browser. Eventually this will impact things like the QuickTime Enabler which relies on the OS to download movie data, which someday no longer can.

I think it's a critical base feature that a Power Mac be able to bootstrap itself and download TenFourFox without having to use another computer. There is no way I can host several hundred megabytes on Floodgap itself, let alone deal with thousands of weekly downloads, but maybe we can just host a tool to handle the download instead. If you looked in that SourceForge directory already, you saw a new file: the TenFourFox Downloader. Grab it, copy it to one of your computers and see if it can fetch FPR5. It should be able to because it has all the pieces necessary to do so, including updated encryption and certificates, and using it should be self-explanatory. Assuming people report no problems, the Downloader will go live in a week or so and be offered from the main TenFourFox page to users on unencrypted HTTP who are using any non-WebKit browser other than TenFourFox, as well as systems without Leopard WebKit (TenFourFox and Leopard WebKit users will get regular HTTPS links as the site offers currently). While you could use the Downloader to do your version updates, it's really intended just to help new users starting from scratch to get off the ground.

Meanwhile, I'm in the midst of converting Floodgap to HTTPS, and https://gopher.floodgap.com/ is already live (and gets an "A" grade from Qualys SSL Test). However, even though the HTTPS/TLS version of Floodgap will support the latest security practices, there will always be an unencrypted version of Floodgap since I serve lots of old systems that don't even speak SSL. While I think the resurgence of the Gopher protocol means that Gopher is likely the best place for old computers to live, since it's a trivial protocol to implement, there's clients for even very limited systems like the Commodore 64(!), and lots of people in the retrocomputing hobby are rediscovering it, I'll still always offer alternatives to allow old systems to still be as useful as they can be and that means a perennial HTTP fallback just in case. That's what makes the Downloader a viable option.

Back to the invisible new feature. Google's Chrome group announced that they are now blocking "annoying" and "disruptive" ads in the browser. I think it should be applauded that Google is paying attention to this, but bear in mind Google is a media-advertising company first, and this move is a pre-emptive strike to make people not reach for adblockers as much. Instead, they'll rely on Google's adblocker, which, of course, will increasingly comply with the rules to not be as "annoying" and "disruptive" and still show you ads.

I don't care if ads are shown or not, personally. Sites need to make a buck to stay open, but if they're going to make that buck by being indiscriminate about what ad networks they use and inconsiderate of the burden they place on their viewers, then they should expect to be blocked. On our older, slower and more resource-limited systems, annoyances are not merely limited to obnoxious images and pop-over-under-arounders, but also larding sites up with additional processing from web scripts. This processing rarely benefits us directly, is usually used to spy on us, increases page load times and can bring the browser to its knees if multiple scripts are competing for the CPU because of JavaScript's "run to completion" semantics. But this isn't what Google wants to block, because these sorts of spy scripts are how they and their allied advertisers acquire their analytics.

Thus, may I present TenFourFox's basic adblock. Calling it adblock is sort of a misnomer because it's really a script block, but those scripts are usually loading ads or ad support libraries, so it achieves a similar effect. Basic adblock is implemented as a simple internal built-in blacklist. This blacklist is implemented at the "caps" level in the browser in C++, so it runs at native code speeds and can check very quickly (far, far faster than any adblock add-on, even Bluhell Firewall), and entries in the blacklist not only are marked as restricted and unable to execute code, but because they are marked as restricted, other components referencing them like adblocker-blockers also are unable to execute. The blacklist contains many common ad networks and "monetization" systems, as well as tag aggregators, user "engagement" and analytics systems, cryptocurrency miners and certain other types of arguable malware, all the major categories that make our lives online hell. The browser speeds up because there are many fewer scripts competing for resources, there are fewer pauses for garbage collection and there is less memory in use, and overall browsing performance improves.

The basic adblock is just that: basic. There is no claim that it is complete, nor will there ever be such a claim. Ads such as cooperative sponsorships that simply load images and aren't script-based, for example, will still appear (and, arguably, should; there's no easy way to distinguish such things programmatically). It's possible to add an imageblocker implemented in a similar fashion as well, but this would rapidly get into a situation where the overhead of scanning for these images exceeds the overhead of just displaying the images themselves (whereas the overhead of many of the scripts we block far exceeds any CPU time spent checking for them). For that matter, some scripts may just simply not be in the list yet. Similarly, the adblock is designed so that the functionality of a given site should remain basically the same whether it is enabled or not, which is why I haven't added entries for things like Disqus because they are part of the comments functionality on many sites, and Disqus may display some ads.

In addition, I had a firm rule while constructing the blacklist that if there is any ambiguity of what exactly is being blocked during the testing of an individual entry, or the entry causes a site to lose important features or fail to properly load, then that entry won't be added. Even when basic adblock is visibly exposed to users, it will never be enabled by default for exactly this reason. But the beauty of this scheme is that it's additive: if what's there (and it will be expanded) is not enough, you can use private browsing mode to block even more tracking scripts, or you can add an adblocker on top of basic adblock for even greater restrictions, depending on your taste and how much overhead you want to devote to that purpose.

To test it out, I first recommend either disabling or entirely removing any existing adblock or anti-tracker add-ons before you update so you can see basic adblock in its truest form. Update to FPR6b1, and in about:config set tenfourfox.adblock.enabled to true (you don't need to restart the browser). Open the MacOS Console (i.e., Console.app) and load a typical media website. Wow, look at what gets blocked! If you don't care for the running tally spamming your system log, set tenfourfox.adblock.logging.enabled to false. Logging will be disabled when the feature is released and finally exposed to users in the TenFourFox preference pane, but the log this option generates will be necessary if you need to report a site that basic adblock seems to disable or cause malfunctions on. I'm interested to hear your comments and how it interacts with other privacy add-ons, even though I myself am now surfing "naked" with only basic adblock so that I can try my own dogfood. I will be adding entries up until the FPR7 beta since the feature is not officially released yet, but once it becomes public (likely FPR7), new entries will only be added during the beta-test period to reduce regression risk from improperly or incompletely screened additions.

Wednesday, January 31, 2018

And everything under the sun is in tune
But the sun is eclipsed
By the moon

(Taken with a Canon PowerShot SX1 IS between 3:45 and 5am Pacific time from Orbiting Floodgap HQ in Southern California, processed on my trusty Quad G5. The timelapse came out wonderfully with a bit of manual correction.)

Sunday, January 28, 2018

I'm typing this in an early build of TenFourFox Feature Parity Release 6. This version contains speculative fixes for hangs on Facebook and crashes with textboxes on some systems, plus tuned-up UI, accelerated video frame colour conversion and -- the biggest feature -- basic adblock integrated directly into the browser core. The basic adblock is effective enough that I've even started running "naked" without Bluhell Firewall and it's so much quicker that there's no add-on overhead. I have some more features planned with a beta somewhere around mid-February. Watch for it.

I bought the Talos II because I wanted something non-x86 without lurking proprietary obscenities like the Intel Management Engine (or even AMD's Platform Secure Processor) that was nevertheless powerful enough to match those chips in power, and the only thing practical and even close to it is modern Power ISA. It had to be beefier than the Quad G5 I'm typing this on, which is why beautiful but technically underwhelming systems like the AmigaOne X5000 were never an option because this 11-year-old Quad mops the floor with it (no AltiVec, wtf!). It had to be practical, i.e., in a desktop form factor with a power draw that wouldn't require a second electrical meter, and it had to actually exist. Hello, Talos. It was pretty clear even before I decided on the specific machine that my next desktop computer wasn't going to be a Mac; I briefly toyed with gritting my teeth and waiting around for whatever the next iteration of the Mac Pro would be, but eventually concluded pro users just weren't a priority demographic to Apple's hardware designers anymore. After all, if we were, why would they make us wait so long? And why should I wait and pay buck$$$ for another iteration of an architecture I don't like anyway?

That's the absolute last straw for me. Sure, as someone who actually uses them on my internal network, I could reinstall them or anything else Apple starts decommissioning in Homebrew (right up until Apple takes some other component away that can't be easily restored in that fashion, or decides to lock down the filesystem further). Sure, hopefully if I upgrade (I use this term advisedly) my Haswell i7 MacBook Air from Sierra to High Sierra, I might not have too many bugs, and Apple might even fix what's left, maybe, or maybe in 10.14, maybe. Sure, I could vainly search for 64-bit versions of the tools I use, some of which might not exist or be maintained, and spend a lot of time trying to upgrade the ones I've written which work just fine now (breaking the unified build I do on my G5 and being generally inconvenient), and could click through the warning you'll now get in 10.13.4 whenever you open a 32-bit app and leap whatever hoops I have to jump through on 10.14 to run them "without compromise."

Sure, I could do all that. And I could continue to pay a fscking lot of money for the privilege of doing all that, too. Or, for the first time since 1987, in over thirty years of using Macs starting with my best friend's dad's Macintosh Plus, I could say I'm just totally done with modern Macs. And I think that's what I'll be doing.

Because the bottom line is this: Apple doesn't want users anymore who just want things to keep working. Hell, on this Quad in 10.4, I can run most software for 68K Macs! (in fact, I do -- some of those old tools are very speedy). But Classic ended with the Intel Macs, and Rosetta crapped out after 10.6. Since then every OS release has broken a little here, and deprecated a little there, and deleted a little somewhere else, to where every year when WWDC came along and Apple announced what they were screwing around with next that I dreaded the inevitable OS upgrade on a relatively middling laptop I dropped $1800 on in 2014. What was it going to break? What new problems were lurking? What would be missing that I actually used? There was no time to adapt because soon it was onto next year's new mousetrap and its own set of new problems. So now, with the clusterflub that Because I Got High Sierra's turned out to be, I've simply had enough. I'm just done.

So come on, you Apple apologists. Tell me how Apple doesn't owe me anything. Tell me how every previous version of OS X had its bugs, and annual major OS churn actually makes good sense. Tell me how it's unfair that poor, cash-starved Apple should continue to subsidize people who want to run perfectly good old software or maintain their investment in peripherals. Tell me how Apple's doing their users a favour by getting rid of those crufty niche tools that "nobody" uses anyway, and how I can just deal. If this is what you want from your computer vendor, then good for you because by golly you're getting it, good and hard. For me, this MacBook's staying on Sierra and I'll wipe it with Linux or FreeBSD when Sierra doesn't get any more updates. Maybe there will be a nice ARMbook around by then because I definitely won't be buying another Mac.

Saturday, January 20, 2018

TenFourFox Feature Parity Release 5 final is available for testing (downloads, hashes, release notes). There are no other changes other than the relevant security updates and the timer resolution reduction for anti-Spectre hardening. Assuming no major issues, it will become live on Monday evening Pacific time.

For FPR6, there will be some bug fixes and optimizations, and I'm also looking at the feasibility of basic CSS Grid support, requestIdleCallback() (using our Mach factor code to improve system utilization), date-time pickers and some JavaScript speedups. Also, I'd like to welcome fresh meat new contributors Ken and Raphael who have submitted fixes for compiling TenFourFox with gcc 4.8.5 and are working with me on support for gcc 6.4.0, where we currently have a startup crash if optimization is enabled. If you're interested in helping us investigate, see issue 464.