Something of an obscure one here, but documented in case anyone else finds this useful.

XQuartz 2.7.10 introduces changes to the Xt library which can have a significant impact on older Motif applications. In IDL, for example, using the dialog_pickfile() function leads to an instant crash with an error message:

IDL> file=dialog_pickfile()
Warning: Dialog style must be XmDIALOG_MODELESS.
Error: attempt to add non-widget child "dsm" to parent "idl" which supports only widgets

if [ "$DYLD_LIBRARY_PATH" = "" ]; then
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR"
    #DYLD_LIBRARY_PATH="$BIN_DIR"
else
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR:$DYLD_LIBRARY_PATH"
    #DYLD_LIBRARY_PATH="$BIN_DIR:$DYLD_LIBRARY_PATH"
fi

if [ "$APPLICATION" = "idlde" ]; then
    # add bindir for idlde shareable libraries
    #DYLD_LIBRARY_PATH="$BIN_DIR_IDLDE:$DYLD_LIBRARY_PATH"
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR_IDLDE:$DYLD_LIBRARY_PATH"
    IDL_START_DIR_DARWIN=`pwd`
    export IDL_START_DIR_DARWIN
fi

An interesting problem started to pop up for Chrome users starting on Friday 14th – Chrome was unable to connect to any Google website. Other browsers were fine, but Chrome was having none of it.

A recent update to Chrome seems to be favouring the use of Google’s new QUIC protocol to connect to their servers, rather than HTTP(S). At the moment QUIC is blocked at the campus firewall so this doesn’t work, but Chrome doesn’t seem to want to give up, and decides that if it can’t have QUIC then you’re getting nothing.

At the moment the only way to fix things is to block the use of QUIC. Open a new Chrome tab, and enter the address:

chrome://flags/#enable-quic

and change the popup menu from ‘Default‘ to ‘Disabled‘. Chrome will then ask to restart and once that’s done all should be well again.

Update – 19th Oct – Networks are aware of the issue and working to enable QUIC through the firewall. The issue has been replicated on a lot of Macs and also Windows 10 systems.

Update 2 – 19th Oct – Even with the firewall allowing QUIC to pass through it seems that Chrome v54 – which started auto-deployment last week – has a bug which triggers this issue. There similar reports on the Chrome releases blog. We may have to wait for Google to fix this! Chrome v53 seems to behave properly – either using QUIC or else falling back to HTTPS as it should.

Update 3 – 21st Oct – Chrome 54.0.2840.71 has been released which appears to fix this problem! If you disabled QUIC I don’t see much to gain by re-enabling unless you’re feeling keen.

I installed Sierra on my Mac today as there didn’t seem to be any major known issues affecting my configuration, and I had updated all my core apps to Sierra compliant versions. So far I’ve found one anomaly.

When printing to the MFDs I keep getting prompted for my AD credentials. My Mac isn’t bound to the AD, but in pervious versions of OS X when I had entered my staff number and password, and selected to store them in the Keychain, I would never be prompted for them again. Printing ‘just worked’. On Sierra I get the prompt for credentials each time; the dialog is pre-filled with the correct data so all I need to do is hit enter or click OK, but it’s annoying!

I have tested this on various machines, both upgrades to Sierra and fresh installs, and on new and upgraded user accounts. All show the same behaviour. It seems the same as discussed on this thread in Apple Discussions. I don’t think this is a change for the better, so I have lodged a bug report with Apple.

Update 16 December 2016 – Apple has addressed this issue with macOS 10.12.2 by adding a preference to revert to the previous behaviour.

OS X is now macOS, and macOS 10.12 shipped yesterday. You may well be seeing prompts to download and install from the App Store. At the moment I suggest waiting a few weeks to let the initial bugs be found by others, and for the inevitable .1 release to come out.

Third party software is still being updated for Sierra; while developers have had access to beta versions there are always glitches with the actual release. For example, Mathematica is known to have issues with some localisations.

Symantec has support for Sierra in their latest Mac release and I am working to get a copy of that uploaded to Managed Software Centre ASAP. Other software updates will be uploaded when they’re available!

Just spending the summer writing documentation. Yay.

I discovered today – via the staff roundup – that staff now have access to Office365. This gives us web apps, 1TB of space on OneDrive, and install rights for Office on PCs, Macs, phones, and tablets. So no more buying O365 licenses to use on iPad Pros!

Point a browser at https://office365.qub.ac.uk to have a look around. You can use your QOL credentials, in the form staffno@ads.qub.ac.uk, to activate Office on iPads, etc.

El Cap 10.11.3 shipped a day or so ago, and I promptly installed on my Mac Pro. Often I counsel a day or two delay in such updates in case of problems, but in this case 10.11.2 was causing me such annoyance that I didn’t think it could get worse – I was badly hit by a bug which affected waking high-res screens from sleep.

Anyway, so far 11.3 seems OK. The monitor wake issue is fixed. Apparently the problem removing receipt files which was introduced in 11.2 is fixed, so that makes Munki happy again. And Mail.app has not obviously started using 150% CPU while sitting doing nothing. So that’s all good, and maybe it’s time to think about updating to El Cap if you haven’t already done so.

I’m publishing this post in the hope that it’s helpful to someone Googling for help. Obviously you should exercise caution when you read anything on the internet, and this involves running your Mac in single-user mode and using the command line. If you’re not comfortable with this then ask someone to assist you. And if this causes your computer to explode then don’t blame me – anyway, you have a backup, yes?

I’ve seen numerous Macs running Yosemite encounter a situation where, for some reason or other, they need a forced reboot but then refuse to start up properly afterwards. Typically this ends up needing an OS reinstall to fix, despite everything appearing to be OK.

The typical sequence of events is that the Mac ‘goes bad’ for some reason or other, and gets powered off forcibly. On reboot things progress OK until the login sequence hangs with the progress bar around 1/3 the way along, generally freezing just after the mouse pointer becomes visible in the top left corner of the screen. The mouse can be moved around, but the machine is never booting, no matter how long it takes.

When booted to recovery mode all checks out OK. The machine can boot in single user mode too and nothing is obviously wrong, though the system logs in /var/log/system.log show rapid turnover and are full of errors about launchd tasks such as mDNSresponder failing to start due to “file or directory not found” errors. However the files in question are all there when one types ‘ls’.

Typically at this point one just gives up and reinstalls OS X, which is thankfully relatively straightforward these days. However today I was poking about some more, and worked out that the problem (for at least this Mac) was not that the files were not present, but that they were not accessible for the daemon users trying to run them – it turned out that the Unix permissions on the root partition were wrong.

The Unix permissions for root portion (/) in OS X should be 755 – or rwxr-xr-x – which means root can read/write/execute and group/other users can only read/execute. For whatever reason – maybe a bad remount after the forced shutdown – the execute bits were no longer set on this machine, so only processes running as root could access the drive properly. Since OS X tries to run most daemons as non-root users, they kept failing and booting stalled. All I had to do was chmod the root partition back to its proper settings and all was well again. To do this

• Boot the Mac in single user mode – hold Command-S at boot until the screen turns into a black background with white text scrolling past
• Make the hard drive writable by typing
  • fsck -fy
  • mount -uw /
• Check the permissions on the root (/) mount by typing
  • ls -ld /
• If the start of the line this command displays is not drwxr-xr-x then type
  • chmod 755 /
• Finally type exit and press return to restart the machine

Hopefully at this point the Mac will reboot and start up properly. Obviously if the permissions on the root partition are drwxr-xr-x already then you have a different problem…

I’m still not having fun with El Capitan, even after 10.11.2 shipped.

First problem – for people who upgrade from 10.10 and earlier using the App Store installer, the contents of /var/db/receipts/ are deleted – this means that Munki, and any other program which depends on installer receipts to keep track of installed software, decides nothing is installed and wants to reinstall everything. This is tedious, but not terminal, I guess. The problem does not arise when updating an existing 10.11 install to 10.11.2, at least.

Second problem – and one which is directly affecting me and is therefore a crisis – is that detection of multiple displays seems flaky. I have a Mac Pro (trashcan model) with two external displays. While I’ve had intermittent issues with display detection, after applying 10.11.2 it’s been hideous – generally only one display will detect reliably, though if I power everything down and up again maybe it will work after a half hour of cable shuffling. Most vexing. Only way around it at the moment seems to be not letting screens go to sleep once they’re working, which is hardly satisfying.

At the moment I think that if Yosemite is working out OK for you, stay there!

Migration Assistant is one of those things which will either work perfectly (most of the time) and save you much effort, or else will fail in interesting and subtle manners and annoy the heck out of you until you fathom what it did wrong.

Most recently I was migrating someone from a 2007 iMac to a nice new 27″ 5K iMac – quite the update. I only migrated their user account – I tend to reinstall apps from scratch, especially with such a significant migration. All seemed OK at first, but a few issues came up:

• Google Drive would not sync – when double-clicking the App icon it would only open the sync directory, but not actually run
• Latexian could not export a PDF if it involved overwriting an existing file
• The Trash was not working – if you tried to drag something to it the only option was to delete immediately

The first problem turned out to be due to Google Drive having installed various things in ~/Library/Application Support/Google/Drive which were apparently out of date. Deleting this folder and re-running the Drive app sorted that problem out.

The second problem was more subtle, but turned out to be down to incorrect ownership of the user directory. While the username was the same for the new account, the userID number was different. It looks like Migration Assistant created the new account, gave it UID number 502, but created the home directory with the UID 503, which was the UID for the old Mac. All folders within the home directory had the correct ownership, so you were able to read/write properly below that, but nothing new could be created in the home folder, like the .Trashes/ folder. Once I figured this out a quick ‘sudo chown’ fixed things right up.

In summary, to paraphrase President Reagan, one may trust Migration Assistant, but always verify…

This message sponsored by Ming the Merciless…

An interesting story from Ars Technica. Hackers took control of a site which site authors use to inject anti-adblock code to their pages. They then injected code into the site which popped up a window telling users their Flash install was out of date, and offering a link to a download which was – of course – malware.

A few lessons from this –

• It’s still best to have no Flash installed, as then you know it’s a malicious popup
• I’m still going to run AdBlock to avoid compromises of ad servers
• I’m still going to remove Flash on any computer I see