Firefox Vacation

Apple has recently updated Safari (v13) to further restrict the ability of plugins… not actually sure that statement is entirely true without qualification, but for the sake of simplicity it is essentially correct. The immediate result of which is that uBlock-Safari is no longer usable.

The writing has been on the wall for a long time as the project was unmaintained for months – nothing had been pulled from upstream since April of 2018. Yes, it still worked but many of the countermeasures deployed by the attention thieves were becoming annoying.

Despite having a pi-hole configured on the network, which is blocking some 15 – 20% of requests (yes, that’s right roughly a fifth of the internet traffic is tracking / ads / trash), it’s still useful to be able to block at the element level. This “necessity” has lead me back to using Firefox as my default browser for the first time in many years.

For a long time Firefox on OS X / macOS has been horribly inefficient. Just regular browsing would chew through laptop battery at an amazing rate, playing video would immediately spin up fans. The same usage pattern in Safari is much much better. Lately changes have started to land in the Firefox Nightly release that start to address these issues. My understanding is that it is now using the Core Animation APIs and changing the way the compositing happens. You can read all about it in ticket Bugzilla 1429522.

In the longer term, my plan is to return to Safari as the default browser. What is missing is a content blocker that provides element level blocking… most likely that is going to be 1Blocker but i’ve not got around to validating that is the case.

The reason behind this desire to go back to Safari is not entirely straightforward. Despite being annoyed that uBlock Origin can no longer ship as it once did, the rational behind the change to Content Blocking API is essentially sound: plugins doing content level blocking require full visibility of the data being displayed in order to remove the elements which are blocked. With the new API this is somewhat inverted, the content blocker tells the browser what to block and there is no need to trust a third-party with processing all the data. Yes, it’s a pain to go through the transition but given the amount of trust it is necessary to have in a browser and, by extension, it’s plugins, it makes sense.

However, the above is not the entire story. Despite the improvements in Firefox Nightly, it’s still more power hungry than Safari, it just doesn’t integrate as neatly with macOS. Sharing and hand-off don’t happen. Gesture support is lacking (mostly pinch to zoom, which might be supported, but doesn’t work for me in the nightlies). And finally there are niggles like the reader not being a polished, scrolling not feeling as smooth… things that would eventually become annoying.

In summary: back using Firefox; it’s much improved; will probably stay for a while; still expect to return to Safari in the future.

Sleep Problem

Not me, but my venerable Mac Pro 1,1.

At some point the damn thing stopped sleeping. I’d spend time stopping apps, checking after a clean boot, looking through the output of netstat -an, etc. Nothing. Gave up and just did a lot more shutting down the machine completely. It bugged me but in a way it was good to turn it all off (less checking mail in the middle of the night…)

Today it bugged me again. On the way out to walk around the park i’d tried to sleep the beast, as usual it refused. In a fit of pique i yanked the network connection. Paranoia inspired testing? And, the machine went straight to sleep. Uh huh.

More fiddling around with Privoxy (always a candidate for being the problem in my mind), puzzling through netstat output, closing down apps., etc. More nothing. Bah.

Then, pmset:

$ pmset -g assertions
6/12/13 11:27:34 AM GMT+ 
Assertion status system-wide:
 PreventUserIdleDisplaySleep 0
 CPUBoundAssertion 0
 DisableInflow 0
 ChargeInhibit 0
 PreventSystemSleep 1
 PreventUserIdleSystemSleep 0
 ExternalMedia 0
 DisableLowPowerBatteryWarnings 0
 EnableIdleSleep 1
 NoRealPowerSources_debug 0
 UserIsActive 0
 ApplePushServiceTask 0
Listed by owning process:
 pid 94: [0x0000005e012c0010] PreventSystemSleep named: "com.apple.InternetSharing"

All this time i’ve had internet sharing turned on… and had no idea that it stopped machines sleeping. Seeing as i don’t actually share internet from this machine it’s a little puzzling. No doubt it was turned on for a reason in the past, all that is lost in the mists of time.

Anyway, pmset -g assertions is the way to debug sleep issues! May Gub (or the ghost of Steve) help you if you ever need to read the manpage. At least i can now sleep my machine again!

Things You Don’t Want To Do

So, you have to compile mysql to make sure that a crash has been fixed, otherwise you’re going to end up filing a bug… and we all know how much hassle that can be! Unfortunately you need a 64bit build (x86_64) on OS X… and you’ve never built mysql before.

This is what you need:

$ MACOSX_DEPLOYMENT_TARGET=10.5 \
CFLAGS='-O3 -fno-common -arch x86_64' \
LDFLAGS='-O3 -arch x86_64' \
CXXFLAGS='-O3 -fno-common -arch x86_64' \
./configure -with-plugins=innobase
$ make
$ sudo make install
After that it’s all nice and easy. Up until then… not so much.