Apple has just released its regular weekly update to XProtect, bringing it to version 5336. As usual it doesn’t release information about what security issues this update might address.
This version adds two new rules for MACOS.WANNABEWALLABY.IMA and MACOS.WANNABEWALLABY.STA, amends rules for MACOS.TIMELYTURTLE.DYHEOC, MACOS.SOMA.MAENA, and MACOS.SOMA.MAENB, and changes some rule UUIDs. In the Osascript rules in XPScripts.yr, it amends the rule for MACOS.OSASCRIPT.SYPR.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5336
Sequoia and Tahoe systems only
This update hasn’t yet been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5336 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
For those working with Rich Text without embedded images, my free editor DelightEd offers a suite of unique features. I wrote it when macOS Mojave introduced Dark appearance mode, with the primary purpose of composing Rich Text documents that work independent of appearance. For that it can set styled text on a background that ensures perfect readability in both Light and Dark modes.
Since then it has gained other unique features, including support for creating interlinear text, in which different translations or versions of the same document are interleaved line by line. It will also open PDF documents and automatically extract all their text content.
General features supported include Writing Tools (Apple silicon Macs), case transformations, and a full suite of substitutions. However, until this new version of DelightEd, substitution settings haven’t been saved in DelightEd’s app settings. Version 2.5 now puts that right: to set the app’s default substitutions, set them up using the Substitution command in its Edit menu, for instance enabling Smart Links.
Then save those to its settings using the Save Defaults command in the app’s menu. Each time you open DelightEd after that, its substitutions will start from those saved defaults.
DelightEd version 2.5 for macOS 11.5 Big Sur and later, including Tahoe, is now available from here: delighted25
from Downloads above, from its Product Page, and through its auto-update mechanism.
I’m very grateful to Manuel for asking for this to be fixed.
I hope you enjoyed Saturday’s Mac Riddles, episode 353. Here are my solutions to them.
1: The future was here 25 years ago when the fastest land animal arrived.
Click for a solution
Cheetah (Mac OS X 10.0)
The future was here (launched under the tagline of ‘the future is here’) 25 years ago (released on 24 March 2001) when the fastest land animal (a cheetah, despite Mac OS X 10.0 being far from the fastest) arrived.
2: This atelier came with more than a marathon four years ago.
Click for a solution
Mac Studio M1
This atelier (a studio) came with more than a marathon (the first Apple silicon Mac to feature an M1 Ultra chip) four years ago (announced 8 March and released 18 March 2022).
3: Wicked fast at 40 MHz, its special effects impressed 36 years ago.
Click for a solution
Macintosh IIfx
Wicked fast (it was dubbed ‘wicked fast’) at 40 MHz (the clock speed of its 68030 CPU and bus), its special effects (FX) impressed 36 years ago (released 19 March 1990).
The common factor
Click for a solution
They each celebrated their anniversaries this month.
Many discovered how long 5 minutes could last when they updated from macOS 26.3.1 to 26.4. Right at the end of its Preparation phase, Software Update showed there were only 5 minutes remaining for far longer. This article reveals what went wrong with that update.
My observations come from a Mac mini M4 Pro running a vanilla installation of macOS Tahoe, being updated from 26.3.1 (a) with the BSI installed, to 26.4. Times and details are taken from log extracts covering the final 14 minutes of the update, immediately prior to the reboot for its installation.
Preparation
At almost exactly 18:43:00, softwareupdated reported that the PREPARING_UPDATE phase was in progress, with 70% complete on the progress bar, and 20 minutes remaining. Periodic preparation activities were then reported in the log, mainly verifying components to be installed as part of the update. One of the longest of those, /usr/standalone/i386/Firmware.scap, took nearly 6.5 minutes alone, although you might wonder why that’s required on an Apple silicon Mac!
Eleven seconds later, softwareupdated changed the progress bar to display 10 minutes remaining, with 71% completed. Just 1.5 seconds later that changed again to display 5 minutes remaining with 94% complete. Six seconds after that, with 5 minutes still displayed, the log records 98.6% was complete.
The log and progress bar then remained stuck at 5 minutes remaining and 98.6% complete for the next 11 minutes and 47 seconds, before changing to 99.9% complete and no time remaining.
These are plotted in the chart below.
The final 5 minute period started at 18:43:12, and lasted until 18:55:04, as reflected in the long period of 98.6% completion (upper line) and 5 minutes remaining (lower line).
The “5 minutes” remaining actually took 12 minutes and 7 seconds, although log entries make it clear that preparation continued throughout that time, with further verifications and “Preparing system volume…”. Those details were reported as ActionText for progress monitoring, but curiously aren’t accessible to the user at the time.
Log entries record softwareupdated keeping detailed records of progress over this period, though. For example: 18:51:32.924688 softwareupdated PrepareUpdate PROGRESS (Continue) | state:{
ActionText = "Preparing system volume...";
ElapsedTime = 490;
ExpectedTime = 1335505;
PercentBytesComplete = "48.05373989419242";
PercentComplete = "4.701870471432042";
}
But those aren’t reflected in the progress bar.
Once the update had completed that preparation phase, extensive checks were performed to ensure it was correctly configured, and components were moved into place in the ‘stash’ to be used during installation. One second after successful completion, softwareupdated locked the controller state and waited for the reboot to start installation. Rebooting followed less than two minutes later.
What went wrong?
The macOS 26.4 update for Apple silicon Macs was large, and the work required to verify its contents and complete its preparation was incorrectly reported in both percent completion and time remaining. Even in smaller updates, some form of progress needs to be shown in the progress bar during these later stages of preparation, or users may be mislead into thinking the update has frozen or failed, and could for example restart their Mac to try updating again.
What should the user do?
When an update claims there’s only 5 minutes left, that could readily extend to longer, possibly on slower Macs as long as 30 minutes or more. Unless there’s evidence that the update has gone wrong at this stage, you should leave your Mac to complete it, as it almost certainly will. If you’re still in doubt and want to confirm that the update hasn’t frozen, open Activity Monitor and look for around 100% CPU from softwareupdated or related processes, and disk activity.
Unfortunately, there’s nothing the user can do to accelerate macOS updates.
One of the longstanding jokes in computing is how misleading progress indicators can be, and last week most of us had a timely reminder when we updated macOS. However much we might like a perfectly accurate linear indicator for macOS updates, this is one of those situations where the best we can expect is a compromise, as I tried to explain here.
Showing progress
There are two types of progress indicator, determinate and indeterminate, depending on whether the task is quantifiable and progress is measurable. Determinate indicators are always preferred, as they inform the user whether they need only wait only a few moments, or they have time to enjoy a leisurely meal, but that requires quantifiability and measurability.
The simple example is copying a file from one disk to another: although macOS doesn’t know in advance how long that might take, it can quantify the task as the size of the file to be copied, then keep track of how much of that has already been completed. When half the size of the file has been copied, the progress bar can be set to half-way along its total length, so providing an accurate indication of progress.
However, with some copy operations that breaks down: when copying a sparse file between APFS volumes, for example, only the sparse data is copied, not the whole file size. As a result, copying sparse files often results in progress bars that jump from a low point to completion in the twinkling of an eye. This also relies on the quantities involved being linearly proportional to the time required, an assumption that often breaks down when downloading from a remote server.
macOS updates
Updating macOS consists of a series of many tasks (see references at the end), of which only one, downloading, is both quantifiable and has measurable progress, and even that may be far from linear. Apple therefore has a choice of:
Display multiple progress indicators, appropriate to each phase. While that might work well for the download phase, it can’t work for others, including preparation, which is likely to take a period of several minutes at least.
Combine those into a single progress bar, as at present.
Use an indeterminate progress indicator, such as a spinning wheel, which would be reliable but unhelpful.
As downloading is the one task that is quantifiable and its progress is measurable, I’ll start there.
For this, the progress bar starts an an arbitrary 15%, and softwareupdated assumes the total size of that download is the magnitude of that task.
When the download has been completed, the progress bar reaches an arbitrary 55%, and its caption then changes to reporting progress with preparation.
There is a weakness in the assumption that becomes obvious when downloading from a local Content Caching server, as the final 1 GB or so normally isn’t provided from the cache, but has to be freshly downloaded from Apple’s servers. However, that isn’t normally apparent when caching isn’t available and the whole of the download comes from the same remote source.
For the remainder of the progress bar, between 0%-15% and 55%-100%, the task is neither quantifiable nor measurable. Instead, softwareupdated divides it into a series of subtasks, each of which has a fixed progress level. One list of subtasks and levels obtained from the log is given in the Appendix at the end.
The disadvantage of that strategy is that time required by each subtask varies with the update and the Mac being updated. Inevitably, computationally intensive subtasks will proceed more rapidly on newer and faster Macs, while those mainly constrained by disk speed should be more uniform. Large updates should take significantly longer, and that will vary by subtask as well.
The last 5 minutes
A particular problem with some more recent macOS updates, including that from 26.3.1 to 26.4 last week, has been unmarked progress over the final “5 minutes” of preparation. While indeterminate progress indicators continue to move over that period, and reassure the user that the task hasn’t ground to a halt or frozen, the progress bar shown had no intermediate points, making it easy to misinterpret as failure to progress. If this is going to be a feature of future macOS updates, Apple needs to insert some intermediate points to let the user know that the update is still proceeding.
Conclusion
A progress bar that combines different measures of progress, such as download size and substages, can work well, but only if the user is aware of how to read it. As we only update macOS a few times each year, that isn’t sufficient exposure, and how it works needs to be made explicit.
Input and output have long been key factors in computer performance, and capable of bringing everything to a crawl unless carefully managed. This is most obvious when foreground and background processes contend for common resources such as disk storage. A popular solution has been to impose delays on I/O performed for intensive background tasks, like backing up, so giving more important tasks preferential access to I/O. This policy is known as I/O throttling, and has come to determine hardware choice.
For example, folk wisdom is that there’s little point in wasting a faster drive to store your Time Machine backups, because when those backups are made, their write speed is throttled by macOS.
I/O Throttling
Documentation of I/O policy is in the man page for the getiopolicy_np() call in the Standard C Library, last revised in 2019, and prevailing settings are in sysctl’s debug.lowpri_throttle_* values. Those draw a distinction between I/O to local disks, being “I/O sent to the media without going through a network”, such as I/O “to internal and external hard drives, optical media in internal and external drives, flash drives, floppy disks, ram disks, and mounted disk images which reside on these media”, and those to “remote volumes” “that require network activity to complete the operation”. The latter are “currently only supported for remote volumes mounted by SMB or AFP.”
Inclusion of remote volumes is a relatively recent change, as in the previous version of this man page from 2006, they were explicitly excluded as “remote volumes mounted through networks (AFP, SMB, NFS, etc) or disk images residing on remote volumes.”
Five policy levels are supported for IOPOL_TYPE_DISK:
IOPOL_IMPORTANT, the default, where I/O is critical to system responsiveness.
IOPOL_STANDARD, which may be delayed slightly to allow IOPOL_IMPORTANT to complete quickly, and presumably referred to in sysctl as Tier 1.
IOPOL_UTILITY, for brief background threads that may be throttled to prevent impact on higher policy levels, in Tier 2.
IOPOL_THROTTLE, for “long-running I/O intensive background work, such as backups, search indexing, or file synchronization”, that will be throttled to prevent impact on higher policy levels, in Tier 3.
IOPOL_PASSIVE, for mounting files from disk images, and the like, intended more for server situations so that lower policy levels aren’t slowed by them.
However, the idea that throttled I/O is intentionally slowed at all times isn’t supported by the explanation of how throttling works: “If a throttleable request occurs within a small time window of a request of higher priority, the thread that issued the throttleable I/O is forced to a sleep for a short period. This slows down the thread that issues the throttleable I/O so that higher-priority I/Os can complete with low-latency and receive a greater share of the disk bandwidth.”
Settings in sysctl for Tier 3 give the window duration as 500 milliseconds, and the sleep period as 200 ms, except for SSDs, whose sleep period is considerably shorter at just 25 ms. Those also set a maximum size for I/O at 131,072 bytes. You can view those settings in the debug section of Mints’ sysctl viewer.
Some years ago it was discovered that the user can globally disable IOPOL_THROTTLE and presumably all other IOPOL_TYPE_DISK policy with the command sudo sysctl debug.lowpri_throttle_enabled=0
although that doesn’t persist across restarts, and isn’t documented in the man page for sysctl. This is provided in an option in St. Clair Software’s App Tamer, to “Accelerate Time Machine backups”, for those who’d rather avoid the command line.
Apple silicon Macs
Since the man page for getiopolicy_np() was last revised, Apple silicon Macs have changed I/O. Most is now handled in some way through specialised Arm cores within the chip, and CPU cores come in two (now three) types, Efficiency and Performance (and Super in the M5 family). Background threads such as those performing the work associated with IOPOL_THROTTLE are now most likely to be running on Efficiency (or M5 Performance) CPU cores.
If you wanted to do away with all throttling, you not only have to change the debug.lowpri_throttle_enabled setting, but you’d need to move those background threads to run them on Performance (M5 Super) CPU cores, which isn’t possible unless you have control over the code. There is evidence that macOS may do this anyway when performing the first full Time Machine backup, which achieves significantly faster speeds than subsequent incremental backups.
Dangers
The big disadvantage of completely disabling I/O throttling policy is this can only be applied globally, so including I/O for Spotlight indexing, file synchronisation, and other background tasks, as well as those needing high-priority access to I/O. Leaving the policy disabled in normal circumstances could readily lead to adverse side-effects, allowing Spotlight indexing threads to swamp important user storage access, for example.
Conclusions
Even when Macs were simpler and all CPU cores were the same, disabling I/O throttling was at best experimental, and ran the risk of compromising higher priority I/O. In Apple silicon Macs, relocating threads from E to P cores isn’t possible, except when running them in a virtual machine. Without that, there seems little if any benefit from disabling I/O throttling. However, the claim that there’s no performance benefit to be obtained from faster backup storage media is demonstrably false. Perhaps it’s time to return I/O throttling to the obscurity it deserves.
In most respects, lightweight virtualisation of macOS on Apple silicon delivers almost the same performance as running code on the host. That’s the result of having direct access to CPU cores and the GPU. However, earlier implementations in Monterey and Ventura performed poorly when accessing the Data volume in the Virtual Machine, with read/write speeds measured at 4.4/0.7 and 5.4/0.7 GB/s respectively, without FileVault or other encryption. In macOS 26.3.1 both RAW and ASIF encrypted disk images show disappointing performance particularly when writing to them. This article therefore re-evaluates VM disk performance to see if that extends to VMs.
Methods
Tests were performed on two freshly made 100 GB VMs in RAW format using the macOS 26.4 IPSW, running on a Mac mini M4 Pro in macOS 26.4. VMs were given 5 CPU cores and 16 GB memory, didn’t connect to an Apple Account, and were built and run in Viable and Vimy, both of which use the standard macOS API for virtualisation.
Performance was measured using Stibium’s ‘Gold Standard’ with 5 rather than 10 test sets, reading and writing a total of 26 GB in 80 files ranging in size between 2 MB and 2 GB. Following an initial write test, the VM was restarted before performing the read test. The first VM was configured with FileVault enabled, and the second with it disabled. In addition to those, standard read/write performance was measured as before on a 100 GB RAW disk image on the host, and on a 100 GB ASIF image, both being encrypted using 256-bit AES.
Results
Measured read/write speeds were:
Native SSD, FileVault on – 6.57/7.66 GB/s
VM, FileVault off – 6.62/5.91 GB/s
VM, FileVault on – 4.66/3.11 GB/s
RAW disk image, 256-bit AES – 2.82/1.59 GB/s
ASIF disk image, 256-bit AES – 2.85/1.76 GB/s.
With FileVault disabled, performance in the VM was surprisingly close to that of the host’s internal SSD, with a small reduction in write speed from 7.66 to 5.91 GB/s. That’s a huge improvement on previous results, with writes being almost ten times faster.
Enabling FileVault did reduce performance significantly, particularly write speed which fell to about half. However, those are still good enough to be acceptable for most purposes.
No significant change was seen in host disk image performance from those measured in 26.3.1, though, which remains substantially slower than the VM with FileVault enabled.
Conclusions
VMs are vulnerable if they don’t have FileVault enabled. Without encryption, sensitive contents would be relatively easy to access if the VM were to fall into the hands of an attacker. Enabling FileVault is thus potentially more important for a VM.
Thankfully, with such great improvements in VM disk performance, those hosted on an Apple silicon Mac’s internal SSD are unlikely to be slowed much by their disk performance.
This makes it the more puzzling that encrypted RAW and ASIF disk images should perform so poorly, and it’s disappointing to see that continues in macOS 26.4. Over the same period that VM disk performance has increased so impressively, that of disk images has headed in the opposite direction.
VMs and BSIs
If you tried installing the recent Background Security Improvement (BSI) in a macOS 26.3.1 VM, you were probably disappointed. In this respect, the VM didn’t work as expected. I was unable to find the BSI in its section in Privacy & Security settings. What did help was downloading it using SilentKnight, although that can’t install BSIs successfully. Instead, I restarted the VM and Privacy & Security offered to install the BSI at last.
Once installed, Privacy & Security offered to remove the BSI, but failed to do so, with SecurityImprovementsExtension reporting: Rollback failed: Error Domain=SUOSUErrorDomain Code=103 "Unable to remove Background Security Improvement" UserInfo={NSLocalizedDescription=Unable to remove Background Security Improvement, NSLocalizedRecoverySuggestion=Use Software Update to install the latest version of macOS.}
For the time being BSIs appear dysfunctional in VMs.
Updating macOS is a far more complex series of processes than it used to be, and the progress bar displayed in Software Update settings is complicated as a result. To capture all the phases that precede installation of an update, the progress bar moves through a series of stages, only one of which is downloading. This article identifies and explains them.
Start
When the Software Update pane offers a macOS update, it has already done a lot of the preliminary work, in fetching the catalogue of updates, checking through them to determine which could be installed, and working out what that would require. This enables it to provide a first estimate of how much needs to be downloaded. Note this is only an estimate at this stage, and may not include additional components such as an update to Rosetta 2.
Once you’ve agreed to install the update now, the progress bar is displayed.
Progress shown here covers many different processes, of which the most substantial are the download and preparation phases. Although progress shown during the download will vary depending on the speed of your Mac’s connection with Pallas, Apple’s software update servers, other sections are determined by the completion of tasks required for the installation, and may proceed in fits and starts.
Before the download can begin, softwareupdated has initial preparations to make, including reloading and downloading the Update Brain responsible for much of the task of installation. Following that are extensive preflight checks, and together those account for the first 15% of the progress bar shown. On a fast Apple silicon Mac, the progress bar may jump straight to that 15%.
Download
This starts at that arbitrary 15%, and is completed when the bar reaches 55%. In between those it should progress according to download speed, but that can be highly non-linear.
This displays a more accurate total size for the download, and the current amount that has already been downloaded. In this case, the bulk of this update is coming over the network from my Content Caching server, so its initial estimate is for a brief period of just 2 minutes. The progress bar then moves in proportion to the amount downloaded, not the time.
Although most of the download can be cached, for Apple silicon Macs the last 1 GB or so has to be obtained for each update from Pallas. As a result, the progress bar suddenly slows as it’s approaching 55%, and the estimated time remaining increases before decreasing again.
Preparing
As soon as the download is complete, there’s another preflight phase lasting from 55%-60%, then the downloads are prepared for installation. This phase doesn’t apparently involve their decompression, which is largely performed on the download stream during the download phase.
Preparations are arbitrarily assigned a period of 30 minutes to complete, but now seldom if ever require that long. As they’re allocated to the last 40% of the progress bar, this phase usually completes much quicker than the times given.
The final 5 minutes are often the slowest, and can take a few minutes longer than that, as the files for installation are gathered into a ‘stash’ ready for the Update Brain to install. Because the progress bar tends to jump straight from 95% complete to 100% this can make it look as if the update has frozen.
Installing
As soon as preparations are complete and reach 100% on the progress bar, the Mac prepares to restart into the installation phase, for which you’re given a 1 minute countdown before the screen goes black and installation happens.
Progress bar key phases
0-15% preparation, preflight; usually brief
15-55% download; on Apple silicon Macs, last 1 GB usually can’t be cached, so slower
55-60% preflight; brief
60-100% preparing; last 5 minutes may be longest.
I hope this helps you make sense of what you see during macOS updates, at least until the screen goes black and the installation starts.
Apple has just released its regular weekly update to XProtect, bringing it to version 5335. As usual it doesn’t release information about what security issues this update might address.
This version adds two new Yara rules for MACOS.TIMELYTURTLE.OBDR and MACOS.SOMA.MAENB, and amends the existing rule for MACOS.SOMA.BYTE.SEQUENCE.B. In the Osascript rules in XPScripts.yr, it relocates those for TABUPA, REBUPA, DUVAST, DUCUHA and DUSTCO.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5335
Sequoia and Tahoe systems only
This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5335 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Like any file, a disk image can become corrupt or damaged, and like any mountable disk its file systems can also become corrupt or damaged. Although those should be very infrequent, their results can disastrous, and render the contents of that disk image inaccessible. This article suggests some solutions you can try.
In theory, if the problem is in the image’s file systems, you should be able to mount its volumes and run First Aid in Disk Utility to check and repair them. In practice that seldom works out, as macOS usually refuses to mount the image. Unless you have ready access to a recent backup, all you can do then is resort to Terminal’s command line to attempt a recovery.
Gaining access to the contents of a disk image requires two steps to complete: first the image must be attached as a device, then after probing of the file systems it contains, those can be mounted.
Read-only and compressed disk images have a checksum stored, and this is normally verified against the image file data first. If that proves invalid, then macOS will refuse to go any further.
In the past, records of checksum verifications have been stored in extended attributes such as com.apple.diskimages.recentcksum, and sometimes deleting those, or a record of the file systems being checked using fsck in com.apple.diskimages.fsck, can allow the disk image to mount. More recently those appear to have fallen into disuse.
Next you should try to attach the disk image without verification or mounting. This is best done using a command such as hdiutil attach -nomount -noverify diskImagePath
where diskImagePath is the full path to the disk image file, such as /Users/hoakley/VMs/myImage.dmg
If this succeeds, you’ll be rewarded with a list of the resulting devices, such as /dev/disk4 GUID_partition_scheme
/dev/disk4s1 EFI
/dev/disk4s2 Apple_APFS
/dev/disk5 EF57347C-0000-11AA-AA11-0030654
/dev/disk5s1 41504653-0000-11AA-AA11-0030654
The first is the disk device disk4, and is followed by its two standard partitions disk4s1 and disk4s2. The latter is its APFS container disk5 with its single APFS volume disk5s1. You can now check and repair the last two of those, such as fsck_apfs -y /dev/disk5s1
which should return a blow-by-blow account of the results. If the file system is HFS+ you may also be able to use third-party repair tools such as DiskWarrior.
When you’ve completed the required repairs, detach the disk image with a command like hdiutil detach /dev/disk4
If that fails to make the disk image mountable, some have claimed success by converting the disk image to a different format, using a command like hdiutil convert diskImagePath -format Uxxx -o outImagePath
where diskImagePath is the original disk image, outImagePath is the new image to be created, and Uxxx is the name of a disk image type, as listed in the Appendix.
If none of these gives access to the contents you require, then it’s almost certain that the only way ahead is to find the latest backup of that disk image, and use a copy of that.
Appendix: Supported disk image formats
UDRW – UDIF read/write, sparse file from macOS 12
UDRO – UDIF read-only
UDCO – UDIF ADC-compressed
UDZO – UDIF zlib-compressed
ULFO – UDIF lzfse-compressed (OS X 10.11)
ULMO – UDIF lzma-compressed (macOS 10.15)
UDTO – DVD/CD-R master for export
UDSP – sparse image, grows with content
UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
UFBI – UDIF entire image with MD5 checksum.
ASIF – sparse image, grows with content, macOS 15.
The update to bring macOS Tahoe up to version 26.4 is hefty at around 7.15 GB (more than double that if you’re unlucky), and reflects a great deal of bug fixes and improvements in almost every subsystem. Apple provides three good sets of release notes:
General release notes include the addition of an option to use compact tabs in Safari, Freeform’s new Creator Studio enhancements, and a facility for Purchase Sharing in Family Sharing. Oh, and the requisite eight new emoji.
Security release notes list over 70 fixes, many of which are significant, but none are reported as being known to be exploited in the wild at present.
The new build number of 26.4 is 25E246. The Darwin Kernel version is 25.4.0, and XNU 12377.101.15~1.
Apple silicon firmware is updated to a completely different version numbering system, and is now reported as mBoot version 18000.101.7. If you’re running SilentKnight older than version 2.14 (71), then it’s likely that it will crash as a result of this change in firmware version. Please use version 2.14 from here.
Firmware in Intel Macs with T2 chips remains with the previous system, and is updated from 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0) to 2103.100.6.0.0 (iBridge 23.16.14242.0.0,0).
Looking through the bundled apps and /System/Library, there are a great many increments in build numbers reflecting the extensive changes made. Here are a few of the more substantial changes found.
In bundled apps:
Books goes from version 8.1 to 8.4
Freeform, version 4.3 to 4.4
iPhone Mirroring, version 1.5 to 1.6
Music, version 1.6.3 to 1.6.4
Safari, version 26.3.1 (21623.2.7.111.2) in BSI (a) to 26.4 (21624.1.16.11.4)
TV, version 1.6.3 to 1.6.4
Audio MIDI Setup, version 3.7 to 3.8
Digital Color Meter, version 6.10 to 6.11
Screen Sharing, version 6.2 (758.1) to 6.1 (760.4), note the reduction in version number.
In /System/Library:
AGX kernel extensions all have build increments
AppleDiskImages2 kext has a build increment
AppleEmbeddedAudio kext and its plugin kexts have build increments
AppleIntel Graphics kexts have version increments
AppleStorageDrivers kext and its plugin kexts have build increments
APFS is updated from 2632.80.1 to 2811.101.1, suggesting a substantial change has been made
new private frameworks include ASMExclaveSupport, AccelerateOpt, AlwaysOnExclavesDaemon, AnteroAgent, AppRemoteAssets, AudioPasscodeDSP, BNNSOdieDelegate, CookingData, CoreTransparency, DynamicPrefetching, InAppFeedback, NanoPassKit, PartnerVisualSearch, a whole family of Unilog frameworks, and a group of iCloudWeb frameworks
mdimporters updated include those for Application, CoreMedia, Mail, Office, iWork but not RichText.
After seeing the new CookingData private framework, I looked out for RecipeKit, but was disappointed not to see it.
This is probably going to be the last such substantial update to macOS Tahoe, as much of Apple’s engineering effort is transferring to make macOS 27 ready for release as a beta at WWDC in early June.
Freeform joins Creator Studio, with advanced tools and a premium content library
Purchase Sharing in Family Sharing
and eight new emoji.
Security release notes for 26.4 list over 70 fixes, those for Sequoia 15.7.5 list about 56, and those for Sonoma 14.8.5 list about 50. None are reported as being known to be exploited in the wild at present.
Firmware in Apple silicon Macs is updated to a new mBoot firmware version numbering system, with the current version given as 18000.101.7. The macOS build number is 25E246, and Safari is version 26.4 (21624.1.16.11.4). Firmware in Intel Macs with T2 chips is updated from 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0) to 2103.100.6.0.0 (iBridge 23.16.14242.0.0,0).
If you’re running SilentKnight older than version 2.14 (71), then it’s likely that it will crash as a result of the change in firmware version. Please use version 2.14 from here.
I’ll be posting an analysis of what has changed later today.
Updated 09:15 25 March 2026 with firmware details for Intel Macs.
If you’ve installed Apple’s new Creator Studio versions of what used to be its iWork apps, I’m sure you noticed something odd in your Applications folder. For there, side by side, are apps with exactly the same names, two Keynote.apps, two Numbers.apps, and two Pages.apps. This article explains the trickery that went into that.
We take it for granted that what we see in the Finder is truthful, despite obvious trickery like hidden folders, and iCloud Drive which doesn’t really exist at all. When it comes to bundles like applications, the Finder doesn’t actually show the true folder name, but the bundle name set in that bundle’s Info.plist.
You can get an inkling of what’s going on by selecting the two Pages apps and opening Get Info on each.
The old Pages.app looks straight, giving its Name & Extension as Pages.app as you’d expect.
But the Name & Extension given for the new Pages.app turns out to be Pages Creator Studio.app, and that’s the real name of its app folder.
Check both using my free utility Precize and you’ll see they are completely different, with their own inode numbers and paths. Drag them into Terminal and that shows their true names in the file system, of Pages.app (old) and Pages Creator Studio.app (new).
If you have a property list or text editor handy, copy the Info.plist from inside each app bundle and inspect them side by side.
The old Pages app is still playing this straight: CFBundleDisplayName = Pages
CFBundleName = Pages
CFBundleIdentifier = com.apple.iWork.Pages
By comparison, the new app is up to no good: CFBundleAlternateNames = Pages
CFBundleDisplayName = Pages Creator Studio
CFBundleName = Pages
CFBundleIdentifier = com.apple.Pages
There’s a great deal more to accomplishing this with finesse as Apple has done here. Other locations in the app such as its About window and menus also need tweaking to ensure that nowhere breathes a word about the trick that has been pulled. And just to add a bit of spice, apps still using AppKit are quite different from those now using SwiftUI.
My only remaining question is why Apple would want to give the two apps identical names. The primary purpose of setting the CFBundleDisplayName is to accommodate better to the limited display area on devices. An app that has a long full name, like The Time Machine Mechanic, obviously needs to be shortened, and ellipses are a clumsy solution. By giving the app developer the opportunity to display something shorter it makes our iPhones look much neater.
Although it’s a clever trick to pull in macOS, I suspect it’s going to confuse more than it amazes.
I hope you enjoyed Saturday’s Mac Riddles, episode 352. Here are my solutions to them.
1: British sister of ANSI is Tahoe’s child of RSR.
Click for a solution
BSI
British sister of ANSI (The British Standards Institution, or BSI, is the UK equivalent of the American National Standards Institute) is Tahoe’s child of RSR (it’s the macOS 26 reimplementation of Rapid Security Responses from Ventura).
2: Puzzle vault in the Da Vinci code contains Safari.
Click for a solution
Cryptex
Puzzle vault in the Da Vinci code (in Dan Brown’s novel ‘The Da Vinci Code’, it’s a portable cylindrical vault resembling a combination lock, used to contain secret messages or precious objects) contains Safari (recent versions of macOS include two cryptexes, the App cryptex containing Safari, and the OS cryptex containing dyld caches).
3: The sound of a liquid hitting a surface could be 1 or its parent.
Click for a solution
Splat
The sound of a liquid hitting a surface (a splat) could be 1 or its parent (it’s Apple’s internal name for the cryptex updates in RSRs and BSIs).
The common factor
Click for a solution
They all refer to the sealed disk images used by recent versions of macOS.
One of the biggest penalties in using disk images has been their performance, particularly when they’re encrypted. Although no longer offered in Disk Utility, UDSP sparse images encrypted using 256-bit AES typically read and write as slow as 500/100 MB/s when mounted from an SSD delivering 4.7/4.9 GB/s. In contrast, UDSB sparse bundles can achieve close to that native speed.
macOS Sequoia brought a new type of disk image, Apple Sparse Image Format or ASIF, intended to deliver the high performance of sparse bundles, with their efficient use of storage space, in a single file that can be hosted on file systems beyond APFS. As this is now well over 18 months old, this article considers whether it has achieved those goals, and should become the preferred type of disk image.
Methods
Each test image was created using Disk Utility 22.7 (2510) in macOS 26.3.1 (a) running on a Mac mini M4 Pro, on its internal SSD of 2 TB. Performance measurements were made using the ‘gold standard’ method in my free Stibium on disk images of 100 GB nominal size. This writes and reads a total of 53 GB in 160 files ranging in size between 2 MB and 2 GB. As performance is likely to change with use of the disk image, the following sequence of events was used:
Create disk image, which is mounted automatically, so unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, then delete the last 8 of 10 sets of test files, and unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, then delete all test files, and unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, and unmount.
These provide three pairs of read/write measurements:
for an empty, unused 100 GB disk image;
for a 100 GB disk image containing over 10 GB of existing files in addition to 53 GB of test files;
for an empty 100 GB disk image that had previously contained about 66 GB of test files that had been deleted.
Disk image sizes were also measured when unmounted, using Precize or the Finder’s Get Info (for sparse bundles).
The three types of disk image tested were RAW (UDRW), UDSB (sparse bundle) and ASIF (sparse image). Each was tested fully when unencrypted, and test 1 was performed on an image encrypted using 256-bit AES.
Results
The best and most consistent performance was achieved by UDSB sparse bundles, as expected. Their read speeds were 6.13, 6.12 and 6.19 GB/s, and write 7.62, 8.03 and 7.79 GB/s for the three separate measurements, and 5.09/5.23 GB/s read/write when encrypted. When first created, the sparse bundle only occupied 32 MB on disk, but by the end had grown to 3.99 GB even though empty.
The RAW disk image, formerly known as UDRW, also largely performed as expected. Read speeds were 6.09, 6.10 and 6.08 GB/s, and write 10.11, 9.86 and 10.11 GB/s. Initially it only required 5.78 MB on disk, rising to 621 MB at the end. However, its performance when encrypted was disappointing, at 2.84/1.58 GB/s read/write.
ASIF disk images were good, but also ran into problems when encrypted. Unencrypted read speeds were 5.99, 5.88 and 5.85 GB/s, and write 9.55, 8.93 and 9.64 GB/s. When encrypted, those fell to 2.82/1.72 GB/s read/write, no better than the RAW disk image. The image file size started at 26.8 MB on disk when empty and unused, and returned to 954 MB when empty at the end.
To confirm that ASIF performance when encrypted wasn’t an anomaly, I repeated that pair of tests on a MacBook Pro M3 Pro running 26.3.1 (a), and obtained similar results at 2.63/1.52 GB/s read/write, using a 10 GB ASIF image with one-tenth of the tests, giving 3.32/1.65 GB/s, and using Blackmagic, which gave 2.92/1.15 GB/s read/write. Although there is variation, they appear remarkably similar.
Test 2 results are summarised in the table above, for ease of comparison, and with the earlier results from macOS 26.0 below.
What has gone wrong with encrypted writes?
Although most of the test results in macOS 26.3.1 are very similar to those from 26.0, performance when using 256-bit AES encryption has fallen for all three disk image types, and most significantly in write performance for RAW and ASIF images, which have reduced from 4.3 to 1.58 GB/s (RAW) and from 3.9 to 1.72 GB/s (ASIF). The magnitude of those reductions is sufficient to have obvious impact on their use. Compared to native write performance using FileVault of 7.66 GB/s, those two types of disk image are pedestrian in the extreme, turning that blisteringly fast SSD into the equivalent of 20 Gbps over USB 3.2 Gen 2×2.
It’s possible that this dramatic reduction in encryption performance may have resulted from a change to address a vulnerability, but I’ve been unable to identify an entry in Apple’s security release notes that might correspond to such an event. I will repeat these tests once the update to macOS 26.4 has been released, in the hope it might be reversed.
Which disk image type?
When their folder-based structure is acceptable, UDSB sparse images remain the disk image type of choice, for their consistent high performance even when encrypted.
There is little to choose between RAW and ASIF disk images when a single file solution is required. ASIF images are portable to other file systems that can’t support APFS native sparse files, although curiously they too are flagged in APFS as being sparse files. As their sparseness isn’t dependent on APFS trimming habits, they are now an alternative that can be used on network storage and NAS. However, those able to use sparse bundles should continue to do so, particularly if using encryption.
If there’s one thing I’ll remember macOS Tahoe for it’s brilliant engineering inside a shockingly flawed interface. Last week’s first Background Security Improvement was yet another example of that trend.
I had enthused about its predecessor the RSR three years ago, although it was sent to the naughty corner after an updated version of Safari told Facebook and other popular sites it wasn’t who they expected. After that trauma, most users shunned RSRs, and it seems engineers who dared mention them were strapped to the front of an F1 car and driven round until they recanted.
Thankfully, RSRs were only put on pause before being rebadged as Background Security Improvements or BSIs, an Orwellian turn of phrase that skilfully avoids the word update despite the fact that they’re still discovered, downloaded and installed by softwareupdated. Now I’ve had a chance to give a fair account of the first public BSI, I can consider what’s wrong with their current implementation.
Location
BSIs are controlled not in Software Update settings, but in their own section at the end of Privacy & Security. As such, they are the only macOS update there, and all others remain in Software Update where they belong. This misleads users, and Software Update reports that Your Mac is up to date when it isn’t, because there’s an outstanding BSI available.
Not only that, but users naturally assume that when Software Update settings have Install macOS updates disabled, no macOS updates will be installed automatically. Little do they realise they can still get a BSI without being asked.
BSIs are currently misplaced in System Settings, and their controls should be moved back to Software Update where RSRs were.
I fear the reasoning behind hiding BSIs among strangers in Privacy & Security was to ensure most Mac users would leave BSIs to be installed automatically. It’s no coincidence that, in addition to this hiding, the automatic installation of BSIs was enabled by default when upgrading to macOS Tahoe. This reeks of deliberate deception.
Control
There is a single on-off toggle provided, to Automatically Install BSIs. Apple explains that “if you choose to turn off this setting, your device will not receive these improvements until they’re included in a subsequent software update.” Thus the user is given a forced choice between macOS deciding when to install an available BSI, or not being notified about that BSI at all.
As with other macOS updates, the user must be given the option to be notified when a BSI is available, and to make their own choice whether and when to install it.
The alternative for users is to disable Automatically Install, watch for news of BSI releases, and, if they wish to receive one, to enable that setting, download and install the BSI, then disable the control again. For many Mac users, that appears to be the best option in the absence of better support.
Although the control is titled Automatically Install, its behaviour is different. When a BSI is found to be available, macOS doesn’t automatically download and install it, but waits for the user to click on the Install button, then to authenticate.
However, if the user isn’t aware that BSI is available, or chooses to ignore it, automatic installation does appear to occur without the user being informed until the Mac is just about to restart, and no authentication seems necessary after all.
This behaviour is the greatest deterrent to users, as it effectively means that their Macs could restart unpredictably with almost no warning, resulting in data loss and disruption to their work. That’s completely unacceptable, and will ensure many will disable BSIs as a precaution to avoid the possibility of data loss. This aversion could be addressed simply by allowing the user full manual control over whether and when a BSI will be installed.
Progress
Despite softwareupdated monitoring progress through the download and preparation phases, the user is shown an indeterminate progress spinner, rather than a progress bar, which would at least give better warning of the restart that is coming. Although much briefer than a full macOS update, a progress bar should be displayed for the download and preparation phases of a BSI.
Restart warning
All previous RSRs, and this first BSI, have required restarts to complete the update. Yet at no time during this BSI was the user told that would be necessary. A notification was displayed a few seconds before the restart, but gave insufficient notice for the user to make any preparations.
It’s essential that information given about the BSI states clearly if a restart will be necessary, and the user is given the same one-minute countdown provided in macOS updates. Bizarrely, the one place that a restart was mentioned is in the dialog to remove a BSI.
Information
Apple’s current support note on BSIs is woefully inadequate, as is obvious by the content of this article. What would appear to be additional information in the BSI settings, marked with the ⓘ Info button, isn’t informative at all, but provides the means to remove a BSI, which is at least an improvement on RSRs, which unaccountably hid removal in the About settings. A more appropriate button should be provided.
BSIs are also only currently covered in the US English version of Apple’s Platform Security Guide. All other localised versions, including British and Canadian English, still contain the outdated section on RSRs. Fortunately, as their content is almost identical, this is revealing rather than misleading.
Version numbering
Ignoring RSR and BSI version numbering, macOS has in recent years achieved clean and systematic version (and build) numbering, without the excesses of the past. By adopting a parenthesised letter as the identifier of a BSI, comparison is clumsy and prone to error. ProcessInfo.processInfo.operatingSystemVersion doesn’t contain a field for the BSI identifier, which is only offered as part of the full string in ProcessInfo.processInfo.operatingSystemVersionString. Version numbers like 26.3.1 (a) and build numbers of 25D771280a are irregular and unnecessary.
Recommendations
BSI controls should be removed from their hiding place in Privacy & Security and put alongside all other macOS updates in Software Update settings.
An option should be provided so that users are informed of the availability of BSIs without any obligation for them to be installed automatically.
Behaviour of the Automatically Install button should be described explicitly to the user. Does it automatically install, and if so, in what circumstances will the user not be so informed?
BSI download and preparation should be accompanied by a progress bar similar to that for a macOS update.
When a BSI requires a restart to complete its installation, the user must be informed of that before they consent to the BSI being downloaded.
When a BSI install is ready to restart the Mac, one minute’s warning notification should be given, just as in macOS updates.
The BSI support note should provide full details, not a sketchy outline.
The button to remove a BSI shouldn’t use the ⓘ Info symbol, but something more appropriate to its purpose.
Apple’s Platform Security Guide should be updated in all its online versions. Is it really that hard to translate from US English to British English?
Version and build numbering should be redesigned to be more consistent and better accessible in the API.
Despite having over three years to get them right, BSIs are a worse mess than RSRs were in Ventura. This is a great shame as their technology is still brilliant, but their current interface is shockingly flawed in so many respects.
A disk image is a file, or a folder containing files, that stores the contents of a physical storage medium. In contemporary usage most can be mounted as a disk or volume, so giving access to their contents. Originally developed to aid the manufacture of floppy disks, they go back long before the Mac, and now see wide use in all parts of macOS and its apps.
Since they were used in Classic Mac OS, they have come in a multitude of different formats and variants, many of which are listed in the Appendix. They’re an essential part of macOS installers, home to Recovery mode, and the basis for cryptexes. They’ve been used to burn and replicate optical disks, to archive disk contents, extensively in network backups, and for the distribution of software.
History
As early as Mac OS 9 in 1999, variants of formats had become complex. Here, Disk Copy is configured to create a read-only compressed .img file containing the contents of a standard 1.4 MB floppy disk. In the upper window, it has completed validating the checksum on a self-mounting .smi disk image that’s part of a DiskSet. Those could also be signed using certificates issued not by Apple but by DigiSign.
Mac OS X 10.1 Puma in 2001 brought a new standard with Universal Disk Image Format (UDIF) used in DMG disk images. Support for compression options in Apple Data Compression (ADC) unified what had previously been two disk image types, and extended support for images larger than a floppy disk. This new format enabled disk images to represent entire storage devices, complete with a partition map and disk-based drivers.
Mac OS X 10.5 Leopard in 2007 introduced the sparse bundle format, with its folder of smaller band files containing data. These enable the image to grow and shrink in size, and became a popular means of storing mountable Mac file systems on servers using different file systems.
Use
In their most common use, Disk Utility or a third-party app such as DropDMG creates and mounts an empty container file, then copies a hierarchy of files and folders into its virtual file system. While the disk image remains mounted, it’s presented as a removable volume, and when unmounted it’s just a regular file that can be moved, copied and backed up like any other.
Its virtual file system can be any supported by macOS, but in recent years is most likely to be APFS. As the disk image can be hosted on a completely different file system, this enables you to store APFS volumes on systems that don’t themselves support APFS. This is essential for networked storage being hosted on a different file system such as Btrfs. SMB can then be used to access the contents of that disk image over the network.
Disk Utility offers a limited range of formats and variants, including RAW images (UDIF), sparse bundles (UDSB), optical disk masters (UDTO), and the new Apple Sparse Image (ASIF). They can be encrypted, and contain file systems in APFS, HFS+, FAT or ExFAT. Two command tools extend those formats and variants, diskutil with its image verb being the equivalent of Disk Utility, and hdiutil providing the most extensive support.
Opening a disk image in the Finder performs two distinct operations: first the file or bundle is attached, much in the way that you might attach physical storage. Once that has occurred, the image is probed by macOS for file structures and systems, and those that can be mounted are mounted as external file systems, normally in the path /Volumes. Cryptexes are an exception to this, as APFS will graft the image’s file system into arbitrary locations in the host file system.
Verification
Two types of verification can be performed during an attach-and-mount procedure. The first can compare the file’s checksum against a stored value to determine if the file has become corrupted, while the second is performed during probing and mounting of file structures and systems within the image. The command tools provide options to attach an image without mounting that can be used to attempt repairs on its file systems, although those seldom seem successful.
This ‘warning’ alert from 2020 illustrates one of the longstanding issues with disk images. Although integrity checking of disk images using checksums has been valuable, when an error is found there’s no possibility of repair or recovery as the image fails to attach, so its file system can’t be made accessible.
Properties
There are two other issues to consider before using disk images, their read-write performance, and use of storage space.
This table summarises read and write performance of the most popular types of disk image prior to macOS Tahoe, and demonstrates how sparse bundles have consistently performed best and most consistently, and sparse images (now dropped from Disk Utility’s options) fare worst, particularly when encrypted.
The introduction of ASIF in Sequoia has added another option, although sparse bundles remain fastest overall. I will be re-examining these in the coming weeks, now that new format has had more time to mature.
Before macOS Monterey, sparse bundles and sparse images were the only formats that made efficient use of disk space, as they grow to accommodate their contents, and should shrink again when some or all of their contents are removed. Monterey is thought to be the first version in which UDIF read/write images (UDRW) have been stored in APFS sparse file format. This has transformed what had previously been space-inefficient disk images that retained empty storage, into a format that can prove almost as space-efficient as sparse bundles.
Summary
Disk images of various formats are widely used in macOS, as they are a file or folder containing a removable file system, like an external disk.
Basic tools for the most common formats and variants are provided in Disk Utility; third-party utilities such as DropDMG are more versatile. The command tool diskutil with its image verb extends those, and hdiutil is the most comprehensive.
Errors can and do occur, and may prevent a disk image from being mounted successfully. Those are hard to repair.
Sparse bundles remain fastest, most consistent, and most space-efficient.
UDIF read/write images generally perform well, and are now space-efficient too.
Experience with more recent ASIF images remains limited, although they show promise in both speed and efficiency.
Appendix: Disk image formats
Supported
UDRW – UDIF read/write, sparse file from macOS 12
UDRO – UDIF read-only
UDCO – UDIF ADC-compressed
UDZO – UDIF zlib-compressed
ULFO – UDIF lzfse-compressed (OS X 10.11)
ULMO – UDIF lzma-compressed (macOS 10.15)
UDTO – DVD/CD-R master for export
UDSP – sparse image, grows with content
UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
UFBI – UDIF entire image with MD5 checksum.
ASIF – sparse image, grows with content, macOS 15.
Unsupported
DC42 – Disk Copy 4.2 (Classic)
DART – compressed, for Disk Archive/Retrieval Tool (Classic)
Rdxx – read-only Disk Copy 6.0 formats
NDIF – Disk Copy 6.0, including IMG and self-mounting SMI
IDME – ‘Internet enabled’, on downloading post-processed to automatically copy visible contents into a folder, then move the image to the Trash. Now deemed highly insecure.
This article explains how to deal with warnings and errors reported either when you run Disk Utility’s First Aid, or by the command tools fsck or fsck_apfs, on an APFS volume or container.
Keep a record
Even if the item is repaired successfully, it’s essential to keep a record of what happened. In Disk Utility, expand the First Aid window so you can see the full output of fsck_apfs, select its whole contents, copy and paste them into a text document, and save that. Do the same with the output in Terminal if that’s what you used.
You may also find two text log files of potential use: /var/log/fsck_apfs.log and /var/log/fsck_apfs_error.log, both accessible in Console or a text editor. Although errors may also be written to the Unified log, you’ll probably want to avoid going there.
Was this on the Data volume?
First Aid in Disk Utility will check and attempt to repair the current Data volume when running in normal user mode, by effectively freezing the Mac. However, that’s not as reliable as running the same procedure when your Mac is in Recovery mode. If you see warnings or errors reported from the current Data volume in normal user mode, before going any further start your Mac up in Recovery and repeat the checks in Disk Utility (or fsck_apfs) there, to confirm they are real, and give your Mac the best chance of making a successful repair.
This can also sometimes help when checking backup volumes, and any that have proved difficult to check because the volume can’t be unmounted in normal user mode.
Are these just warnings?
Read carefully through your copy of the output of fsck_apfs and check whether the comments there are warnings, or contain specific errors. Warnings aren’t uncommon, and are often of little consequence even when you can understand them. Among the commonest is Resource Fork xattr is missing for compressed file
As there’s nothing you could or should do about that, keep the record and don’t worry about it.
You’ll occasionally see a report that “deferred repairs” were completed. These appear to be minor fixes that APFS keeps for a convenient moment. Provided they are fixed without further error, you should be able to ignore them safely.
If a line explicitly reports an error, and fsck_apfs was unable to repair it, then it’s something you should take more seriously, and try to pin down the site of the problem.
Identify the item
fsck_apfs identifies items with their inode number, an integer that can be very large. To make any sense of that, you need the volume number as well, and a means of converting the two into a path. My free utility Mints can do that in its inode Resolver window, from the Window/Data/Inode menu command, or you can do it yourself in Terminal with a command like GetFileInfo /.vol/[volnumber]/[inode]
where volnumber is the volume number, and inode is the number given in the error or warning. This is explained in detail here.
Now that you know which file or folder resulted in the error or warning, you need to decide whether you can do anything about it. This is most important when you keep seeing similar errors, so you can prevent them from happening in the first place.
Is the item in a snapshot?
Checking snapshot 2 of 23 (com.apple.TimeMachine.2023-08-27-072736.local)
warning: inode (id 113812826): Resource Fork xattr is missing for compressed file
Snapshots are a special case, as they’re intended to be read-only, so are most unlikely to be repairable. If this is a snapshot on a volume that is backed up by Time Machine or another utility, then the only way you’ll fix this is by deleting that snapshot. Don’t do that, though, if the snapshot is on the volume storing your backups, as you’d be deleting one of those backups.
If this problem recurs in other snapshots, then it most probably reflects a problem in the file in the snapshot. Is it perhaps a large virtual machine (VM) or something similar? Keep your VMs on a separate volume which you exclude from backups, because of the many problems they can cause. The best way to back up a VM is when it’s shut down, as a simple copy to a separate backup storage volume. You can do the same with any other file that seems to be the cause of repeated problems in snapshots: move it to a separate volume that’s in Time Machine’s list of excluded items, and make arrangements for that volume to be backed up separately when the files aren’t in use.
Is the item in a Spotlight index?
Several of those who report repeated warnings or errors in APFS trace them to part of the Spotlight indexes on that volume, which are stored at the top level of all indexed volumes, in the hidden folder .Spotlight-V100. If that’s the case, your next move is to force those indexes to be rebuilt, in the hope that fixes the problem.
To do that, open Spotlight settings, and click the Search Privacy button at the foot of its window. Use the + tool to add the volume on which the problems have been occurring, then close those settings. Leave your Mac for a minute or so, open those settings again, select the volume you just added to the list, and use the – tool to remove it. In the next ten minutes or so, check Activity Monitor’s CPU window, where you should see high levels of activity from indexing processes such as mds and mds_stores, that confirm those indexes are being rebuilt.
Is the item in another special folder?
There are other hidden folders with special roles that appear on volumes and could be the source of APFS errors. These include .DocumentRevisions-V100, containing the document version database. If the problem file is inside that, there isn’t much you can do about it. It may be possible to delete the whole folder, but that will destroy all saved versions of documents on that volume.
It’s just a regular file
If the volfs path resolves to a regular file, then maybe deleting that file will stop the problem from recurring. Don’t expect a backup copy of that file to be any different, though, as any problem with that file could easily recur. Getting to the bottom of a recurrent file system error might require the knowledge and skills of an Apple engineer. Consider reporting this using Feedback, as it should then help iron out any remaining bugs in APFS.
Is your Mac running anything that might break files?
As a final thought, you should consider whether any third-party software might be the root cause of the problem. Normally, such products should work at a higher level that isolates them from the file system itself, but there are some surprising exceptions. If you can identify a cause, please inform the developers of that software so that it can be fixed.
One potentially dangerous practice occurs when an older version of APFS changes a newer file system. APFS back in High Sierra and Mojave knew nothing of boot volume groups, firmlinks, or many of the features of more modern versions of APFS. If you really must run different versions of macOS on the same Mac, or shared external storage, avoid such version conflicts, and never run an older version of Disk Utility or fsck_apfs on a newer APFS container or volume.
Since the introduction of the Signed System Volume in Big Sur, the great majority of macOS has been strongly protected. So strongly that applying the smallest security patch has required the full might of a macOS update. There are times when something more lightweight enables Apple to promulgate urgent patches swiftly and efficiently, and that’s what a Background Security Improvement or BSI does.
This was set up when macOS Monterey introduced cryptexes to contain Safari, its WebKit supporting library, and the large dyld caches for general support in Frameworks. Cryptexes are cryptographically sealed disk images that aren’t mounted like other volumes, but are grafted into arbitrary locations in the file system. In Ventura they were used for Rapid Security Responses (RSR), in many ways indistinguishable from BSIs.
This week’s first BSI for macOS 26.3.1 is a good example: it fixes one serious vulnerability in WebKit. Rather than building that into a full update to 26.3.2, because it only requires changes in the cryptex containing Safari and WebKit, this BSI swaps out the existing App cryptex and replaces it with a patched one. For those who don’t want to install BSIs, those same vulnerabilities should be fixed in the next set of security updates to macOS.
Controls
Look in Software Update settings, and you’ll see no mention of any BSI, and that will claim your Mac is up to date, even though it’s not.
BSIs are controlled in their section listed close to the foot of Privacy & Security settings. If you want your Mac to be offered BSIs when they’re available, you must enable Automatically Install first. Despite those words, BSIs don’t appear to install in the least bit automatically, and you should be offered those available for the installed version of macOS. When you’ve chosen to download and install one and authenticated, you’ll see a progress spinner rather than a bar.
As soon as downloading and preparation are complete, you should be given a few seconds before your Mac restarts to complete the installation. This is all very brief, but once you’ve authenticated to start the process, it will run through to completion automatically.
Once your Mac has restarted, you always retain the option to remove any BSI and return to an unpatched cryptex. To see that, click on the ⓘ Info button on the right.
If you decide you want to remove the BSI, your Mac will need to be restarted.
Problems
If you know a BSI is available but Privacy & Security settings appear unable to find it, something I’ve encountered in Virtual Machines, try running SilentKnight. Although BSIs aren’t controlled in Software Update, they do still use the same softwareupdate system used by SilentKnight. Normally you shouldn’t try to install BSIs using SilentKnight, as installation will fail. However, you can turn this to your advantage when a BSI is being elusive.
Once SilentKnight has downloaded and failed to install the BSI, you should be notified of that failure. Restart your Mac, give it a couple of minutes to settle once you’ve logged back in, and open the BSI section in Privacy & Security settings again. The downloaded BSI should now be available, and shouldn’t even need to be downloaded.
If you think a BSI has caused another problem, such as instability in Safari, use the ⓘ Info button to remove that BSI.
Installing a BSI does weird things to the macOS version and build numbers, and those can break scripts and possibly some apps. While ProcessInfo.processInfo.operatingSystemVersion doesn’t contain a field for the BSI letter, ProcessInfo.processInfo.operatingSystemVersionString does return a full version description including the BSI letter and extended build number. In Terminal, sw_vers -productVersion returns the regular version number without BSI, while sw_vers -productVersionExtra returns the BSI designation alone.
Currently, SilentKnight and Skint ignore BSIs, and won’t inform you if you could have one installed except by listing it as an available installation, nor will they check whether your Mac is up to date with the latest BSI. Experience from RSRs in Ventura shows that trying to track lightweight updates like RSRs or BSIs is only going to annoy those who don’t want to install them, and as they can change in a short period, they are hard to track reliably. SilentKnight does report the full version and build number, and SystHist lists details of all BSIs that Mac has installed.
Limitations
Like the RSRs of Ventura, BSIs can only work for a limited range of patches. If a vulnerability needs a fix outside Safari, WebKit, and the dyld caches, then it will require a full macOS update to fix it. BSIs are only ever likely to be provided for the current version of the latest major version of macOS.
From its first account of RSRs, Apple has claimed that some RSRs and BSIs shouldn’t require a restart to apply their patches. However, every RSR and BSI to date has had to be completed by restarting that Mac, which is mildly disruptive and not as lightweight as we’d like.
If you disable Automatically Install in the BSI section of Privacy & Security settings, then your Mac won’t be informed about or have access to any BSIs.
Under the hood
Despite their control being part of Privacy & Security settings, BSIs are managed like all other macOS and related updates by softwareupdated. What is most remarkable about them is their speed of download, preparation and installation compared with macOS updates. From detection of a new BSI to logging back into the restarted Mac can take little more than five minutes.
Apple’s in-house term for BSIs is the same as it used for RSRs, Splat. You’ll also come across Semi-splat, which should be a transient state in which the Splat Restore Version is different from the Cryptex1 Restore Version. That’s normally rectified after the reboot.
softwareupdated checks specifically for BSIs by scanning the update server catalogue for Splat updates. In this case, for an App cryptex, the download size is given as 214 MB. There’s a brief preflight phase, followed by its download. Although no progress indicator is shown in Privacy & Security settings, softwareupdated does record progress, but using similar figures for a full macOS update. Under those, preparing the update is set at 60% progress.
Applying the update takes around 2.5 seconds, at which stage softwareupdated reports that Semi-splat is active because of unequal restore versions, and rollback objects are checked.
Once the Mac has restarted, property list paths are checked for six different Splat versions, enabling the restore versions to be rectified and Semi-splat is no longer active. A brief purge of update assets is performed, and softwareupdated checks once again for any available updates.
Is a BSI just an RSR in disguise?
Apart from the move of its control from Software Update to Privacy & Security settings, there appear to be few if any differences between them. This is even reflected in version numbering. Installing the first RSR for macOS 13.3.1 brought it to version 13.3.1 (a), with a build number of 22E772610a. This first BSI for macOS 26.3.1 brings it to version 26.3.1 (a), with a build number of 25D771280a.
Most telling, though, are the accounts of RSRs and BSIs given in Apple’s Platform Security Guide, which are almost word-for-word identical apart from their names. It seems most likely that a BSI is a rebranded RSR in a bid to move on from the loss of confidence in RSRs following unfortunate errors nearly three years ago.
Key points
If you’re running the current version of the latest major version of macOS, BSIs provide lightweight fixes for some vulnerabilities, including those in Safari and WebKit.
Enable them in Privacy & Security settings, in their section at the foot. If they aren’t enabled there, you won’t be offered them at all.
Control their installation in that section. Once you’ve agreed to install one and have authenticated, your Mac is likely to restart automatically soon after the BSI has been downloaded.
Remove and revert a troublesome BSI using the ⓘ Info button there.
Although the US English version of Apple’s Platform Security Guide has replaced its section on RSRs with an almost identical account of BSIs, most other localised versions of that guide still contain the old RSR version.
In my account of how Tahoe updates macOS, I had reached the stage when Rosetta and the main update had started downloading from Pallas, Apple’s software update server (see the Appendix at the end for further explanation of terms used).
Download
Currently, the main update download (at least) is compressed using Zip, and is decompressed as a stream during download, so there’s no delay decompressing during the preparation phase later.
In this case, downloading the main update was completed within 8 minutes. The source of the Zip archive was originally given as a path on [https://]updates.cdn-apple.com/2026WinterFCS/patches, and that was written to a local path on /System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/ In my case, though, I have a local Content Caching Server running, and immediately before the download started com.apple.AssetCacheServices substituted a download URL on that server to ensure the update was obtained through the local caching server. At the same time, an Event Report was sent back to Apple, recording the start of download.
Progress was updated every second during the download, and brought the progress bar from 16% to 53.9% over the following 8 minutes, with little other activity taking place.
Preflight
Activity then changed to what is repeatedly referred to as Preflight FDR Recovery, and is the first entry point for the UpdateBrainService, downloaded for MobileSoftwareUpdate rather than softwareupdated.
This runs an Event Recorder and begins to perform preflight checks to “recover FDR SFR”, and to perform a “firmware-only update”. To prepare for that, it retrieves various nonces and their digests for LocalPolicy, RecoveryOS boot policy, and others. Following those is the first of many attempts to determine purgeable space, in preparation for installation of the update. Those are performed by com.apple.cache_delete.
Pallas was then checked to see if there was any more recent version of RecoveryOS UpdateBrain, but there wasn’t. A further check for any newer recoveryOS was also made, before the main macOS update was prepared, at a progress level of 60% as set previously.
Preparation
The first step of the main preparation phase is to purge staged assets with com.apple.cache_delete. With that complete, UpdateBrainService recalculates cryptex size requirement for the update, and the install target prepare size:
cryptex size is 1.2 times the app cryptex size = 60 MB, plus 1.2 times the system cryptex size = 7749 MB, a total of 7809 MB, as previously calculated;
prepare size is the sum of the snapshot installation size of 3785 MB, the cryptex size of 7809 MB, three ‘slack sizes’ for VW, Recovery and Preboot of 2048 + 1024 + 1024 = 4096 MB, the new template size of 991 MB, twice the update partition size totalling 600 MB, less the old template size of 363 MB. The grand total comes to 16,918 MB.
UpdateBrainService then checks volume free sizes, and confirms that they’re sufficient to complete the update. It next creates a ‘stash’, which is protected by keys in the stash keybag, handled by the Secure Enclave Processor. There is then another round of purging with com.apple.cache_delete.
Much of the preparation phase is spent verifying the protection of installation packages, cryptexes, then the contents of /System/Applications and /System/Library. As progress is about 64% complete, System volume preparations are started, and there’s another round of purging by com.apple.cache_delete. There’s surprisingly little log activity as progress passes 70% complete.
With progress reaching 84% complete, UpdateBrainService starts unarchiving files in parallel, taking just under 5 seconds to complete those. Following that, there’s another brief period unarchiving data files in parallel, then working with the contents of /System/Volumes/Update/mnt1/private/var/MobileAsset/PreinstalledAssetsV2 as progress reaches 87% complete.
When there’s 87.5% completed, UpdateBrainService reports it’s creating hard links in parallel, then is searching for new paths and verifying files, such as those in the Ruby framework. The Recovery volume is unmounted, and there’s yet another purge with com.apple.cache_delete. After those, key volume locations are checked.
The high water mark of disk usage during update is prepared. This reveals some of the steps to be undertaken during installation, including:
prepare source package,
patch cryptexes,
patch system volume,
extract to system volume,
install personalised.
There’s a further round of purging with cache_delete before declaring PrepareUpdate as successful, then suspending the update briefly. When update resumes, the Update volume is mounted and prepared, and there’s another round of purging. The System volume is then mounted, checked, and prepared. Progress is now at 98.5% complete, and once 100% is reached, the countdown to restarting the Mac is begun.
Installation
During the download and preparation phases, apart from repeated purging, the log is generally quiet. This changes dramatically once the Mac starts preparing for shutdown and installation. WebKit is cleaned up and shut down, as are many other processes. The ‘stash’ of update components is then committed, and final scans and checks are completed.
The update is then applied, followed by Rosetta, RecoveryOS, UpdateBrain and finally minor documentation. After that period of nearly 20 seconds, this phase is declared complete, and a restart is notified before waiting for the essential reboot.
Reboot
Once rebooting by root has been initiated, the boot chime is muted to ensure the update continues in silence. The last log message is written a few seconds later, and UpdateBrain then runs the update.
Less than 3 minutes later, the system boot is recorded in the log, and kprintf is initialised 5 seconds later. About 3 minutes afterwards softwareupdated is started up, and runs various clean-up routines to complete the update sequence in conjunction with ControllerSetup and a Finite State Machine.
Key points
The main update download is decompressed while streaming, to save preparation time later.
If a local Content Caching Server is connected, AssetCacheServices will substitute its IP address for that of the Pallas server to ensure the download is obtained through the cache.
Following download, extensive preflight checks are performed.
During preparation components are verified, paths checked, and some unarchiving is performed.
Prior to reboot and installation, processes including WebKit are shut down in readiness for reboot and install.
FDR is unknown, but appears associated almost exclusively with a preflight phase.
Pallas is the internal name for Apple’s software update server. This appears throughout log entries, where for example Pallas audience is jargon for the type of user, normally macOS Customer.
RecoveryOS appears to refer to the version of Recovery in the hidden container of the internal SSD, more widely known as Fallback Recovery.
SFR appears to refer to the version of Recovery in the Recovery volume of the active boot volume group, also known as Paired Recovery.
Splat, semi-splat and rollback objects all refer to cryptexes. Splat is the general term, while semi-splat refers to a cryptex-based update that might include rapid security responses (RSR) and background security improvements (BSI) implemented by replacing one or both cryptexes. Rollback objects are older versions of a cryptex that have been saved to allow a newer cryptex to be reverted to that older one, in the event that the newer cryptex causes problems.
UpdateBrain is the executable code supplied as part of an update that prepares and installs that specific update. There’s a separate UpdateBrainService for RecoveryOS.
Apple has just released its first public Background Security Improvement (BSI) for macOS 26.3.1 Tahoe, labelled as BSI (a)-25D771280a. Once installed, macOS will identify itself as version 26.3.1 (a), with a build number of 25D771280a.
You can install this through Privacy & Security Settings, in the Background Security Improvements section. It doesn’t appear listed in Software Update, although SilentKnight will offer it. Please don’t try to use SilentKnight to install this, though, as it will download successfully but fail to install unless you then use the BSI section in Privacy & Security settings, which will finish the job off.
Apple has now released details of the single vulnerability that this fixes, in WebKit. As a result it updates Safari from 26.3.1 (21623.2.7.11.7) to 26.3.1 (21623.2.7.111.2).
Following installation, your Mac will need to restart for the BSI to be applied.
Apple has just released its regular weekly update to XProtect, bringing it to version 5334. As usual it doesn’t release information about what security issues this update might address.
This version makes no changes to its main Yara rules. Changes to the OSASCRIPT rules in XPScripts.yr include amendments to more than a dozen of them, and two new rules are added for MACOS.OSASCRIPT.GEPEPA and MACOS.OSASCRIPT.TAPEPA. Several rules that previously added the property wide to their text now have wide ascii instead.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5334
Sequoia and Tahoe systems only
This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5334 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
When the same unusual dialog appears twice within a few days for two different people, you begin to suspect a pattern. This article explores a rabbit hole that involves git, the log and the fickleness of AI.
On 8 March, Guy wondered whether an XProtect update earlier this month could have been responsible for a dialog reading The “git” command requires the following command line developer tools. Would you like to install the tools now? As the request seemed legitimate but its cause remained unknown, we mulled a couple of possible culprits, and he went off to investigate.
Five days later, after he had installed the update to SilentKnight 2.13, Greg emailed me and asked whether that might be responsible for exactly the same request appearing on his Mac. This time, Greg had consulted Claude, which asked him to obtain a log extract using the pasted command log show --start "2026-03-13 07:07:00" --end "2026-03-13 07:10:00" --style compact --info | grep -E "14207|spawn|exec|git|python|ruby|make"
Armed with that extract, Claude suggested that SilentKight had been the trigger for that dialog.
I reassured Greg that, while SilentKnight does rely on some command tools, it only uses those bundled with macOS, and never calls git even when it’s feeling bored. While I was confident that my app couldn’t have been responsible, I wondered if its reliance on making connections to databases in my Github might somehow be confounding this.
While I knew Claude was wrong over its attribution, the log extract it had obtained proved to be conclusive. Within a few minutes of looking through the entries, I had found the first recording the request for command line tools: 30.212 git Command Line Tools installation request from '[private]' (PID 14205), parent process '[private]' (parent PID 14161)
30.212 git Command Line Tools installation request from '[private]' (PID 14206), parent process '[private]' (parent PID 14161)
As ever, the log chose to censor the most important information in those entries, but it’s dumb enough to provide that information elsewhere. All I had to do was look back to discover what had the process ID of 14161, as its parent. Less than 6 seconds earlier is: 24.868 launchd [pid/14161 [Claude]:] uncorking exec source upfront
Just to be sure, I found matching entries for SilentKnight and the system_profiler tool it called after the attempt to run git: 30.153 launchd [pid/14137 [SilentKnight]:] uncorking exec source upfront
30.336 launchd [pid/14139 [system_profiler]:] uncorking exec source upfront
There was one small mystery remaining, though: why did Claude’s log show command also look for process ID 14207? That was the PID of the installondemand process that caused the dialog to be displayed: 30.215 launchd [gui/502/com.apple.dt.CommandLineTools.installondemand [14207]:] xpcproxy spawned with pid 14207
Following its previous denial, when Claude was confronted with my reading of the log, it accepted that its desktop app had triggered this dialog. Its explanation, though, isn’t convincing:
“the Claude desktop app calls git at launch — likely for one of a few mundane reasons like checking for updates, querying version information, or probing the environment. It’s not malicious, but it’s poorly considered behavior for an app that can’t assume developer tools are present on every Mac.”
In fact, it was Guy who had probably found the real reason, that the Claude app has Github as one of its four external connectors. However, that shouldn’t give it cause to try running the git command, resulting in this completely inappropriate request.
Conclusions
Claude might know how to use the log show command, but it still can’t understand the contents of the Unified log.
If you’re ever prompted to install developer command tools to enable git to be run, suspect Claude.
What a fickle and ever-changing thing is an AI.*
I’m very grateful to Greg and Guy for providing the information about this curious problem.
* This is based on a well-known English translation of a line from Virgil’s Aeneid, Book 4: “Varium et mutabile semper femina”, “what a fickle and ever-changing thing is a woman”. While all of us should dispute that, there’s abundant evidence that it’s true of Claude and other AI.
I hope you enjoyed Saturday’s Mac Riddles, episode 351. Here are my solutions to them.
1: Show for recording or art, it isn’t as recent as you might think.
Click for a solution
Studio Display
Show (a display) for recording (a recording studio) or art (an art studio), it isn’t as recent as you might think (most recently 27-inch 5120 x 2880 from 2022, but an earlier series of models between 1998-2004).
2: Theatre exhibition was originally the largest of its kind.
Click for a solution
Apple Cinema Display
Theatre (a cinema) exhibition (a display) was originally the largest of its kind (the original model was the largest flat panel display on the market when it was launched in 1999, 22-inch, up to 1600 x 1024).
3: Gallery for pictures of the famous in greyscale only.
Click for a solution
Macintosh Portrait Display
Gallery (a display) for pictures of the famous (portraits) in greyscale only (available between 1989-1992, 15-inch with 640 x 870 in 256 shades of grey).
I’d like to apologise to those of you who ended last week downloading two new versions of SilentKnight, instead of the one that I had intended. This article explains how the second came about.
SilentKnight is heavily dependent on discovering key facts about the Mac that it’s running on. One of the first it needs to know is whether it’s looking at a plain Intel Mac, one with a T2 chip, or an Apple silicon Mac, as that determines how it should go about checking which version of firmware it’s running, and much else.
Over the last five years, SilentKnight has relied on the command-line equivalent of the System Information app, system_profiler. Surprisingly that doesn’t have a single field that draws a clear distinction between those types of Mac. The closest it comes to doing that is the information shown for the Controller item, or system_profiler SPiBridgeDataType
in Terminal:
Intel Macs without a T2 chip return no information, as they’re not considered to have a controller in this sense.
Those with T2 chips return a Model Name of Apple T2 Security Chip.
Apple silicon Macs give the iBoot (or, from 26.4, mBoot) firmware version number.
While that has worked for five years, for SilentKnight version 2.13 I decided to slightly extend the text it looks for, to ” T2 ” to reduce the chance of false positives now that Apple silicon results are becoming more diverse. That worked fine on my two Intel Macs with T2 chips, but broke weirdly in a MacBook Pro tested by Jan, to whom I’m deeply grateful for the early report of this problem. Jan’s MacBook Pro was thoroughly confused, found and reported the correct T2 firmware but told them it should be running a more recent version of iBoot, for Apple silicon Macs.
It turned out that Jan’s MacBook Pro is running German as its primary language, so instead of reporting Apple T2 Security Chip in system_profiler it returned Apple T2-Sicherheits-Chip, and ” T2 ” couldn’t be found to confirm it wasn’t an Apple silicon Mac. The simple fix was to remove the trailing blank from the search term, which becomes ” T2″.
Although system_profiler can return its information in plain text, JSON or XML formats, its content is the same in all three, with localised text that’s dependent on that Mac’s primary language setting. Besides, its XML is exceptionally verbose, squeezing a few lines of information into 262. I was surprised by this five years ago, when I first came across it when trying to parse the list of Apple silicon security settings.
Here you can see those for a Mac using Dutch localisation. Instead of responses like Secure Boot: Full Security
using Dutch for your Mac’s primary language turns that into Secure Boot: Volledige beveiliging
When SilentKnight tries to work out whether your Mac is set to Full Security, that means it would have to look up the response in a dictionary containing every possible language.
Not only that, but these localised responses vary between different sections and data types.
The above responses to system_profiler with French set as the primary language demonstrate that has no effect on Hardware data, where core types are given in English, but changes those in Controller’s Boot Policy. To discover which change, you have to test with many different language settings, as none of this is documented, of course.
At that time I spent several days trying to get an unlocalised response by running system_profiler in an English environment, but that had no effect, and there was no way to bypass this localisation. As this language dependency limits the usefulness of the command tool, I argued that its output shouldn’t be localised at all.
Now, five years later, I have been bitten again, and apologise for putting you through two updates to SilentKnight when there should only have been one.
I expected my first internship to be baptism by fire. As the most junior doctor to two teams of neurosurgeons, I knew I’d learn plenty of new skills, among them performing lumbar punctures. Within the first few days I had been guided through that, and for much of the next six months I averaged one every couple of days. In the 45 years since I completed that job, I haven’t performed another lumbar puncture, ventricular tap, tracheostomy, or any of the other techniques I had learned. I suppose if it was a matter or life or death, I could just about remember how to drill a burr hole in an emergency, but all those other skills have now faded, some in a matter of months.
Skill fade is a distinctively animal trait, and a function of our brain. It comes in degrees: the slight fade you get from a good vacation is quickly overcome once you’ve got your feet back under the desk; more noticeable amounts from a longer maternity or sickness absence might merit a couple of weeks ‘returning to work’; and after a year or two you’ll probably need a period of formal retraining.
For the last year or so there have been increasing concerns raised over the effects of AI on critical thinking, and the Harvard Gazette published an interesting range of opinions last November. There has been extensive discussion about the dangers of ‘cognitive atrophy’ and impairment of critical thought, but less about longer-term skill fade.
I write code because I enjoy doing so. I’m not good at coding by any means, but over the forty years that I’ve been learning to code I have had a great deal of pleasure. It’s a creative act, like painting, involving a rich range of cognitive skills including plenty of art. At the end you have created something of substance, that might also benefit others.
So when someone comes along and advises me to start using Claude or another AI to write code for me, I can’t understand why I might want to stop coding and learn how to brief something else to steal my pleasure, any more than I might ask an AI to make me a painting. Moreover, were I to hand over one of my pleasures in life to AI, I know I’d find it progressively harder to code myself. While I might grow increasingly skilled at getting the AI to do much of the work, I’d also become increasingly dependent on its coding skills rather than mine.
At my age, that would remove one of my defences against the onset of dementia, and free up time to go painting more often. But what would it mean to a young engineer at the start of what they intend to be a bright career? At a time when their skills should only be developing, they’d be letting them fade. And who is going to have skills to transfer when they teach the next generation?
This extends beyond coding. Many of us are handing our writing to AI for it to summarise, one of its undisputed strengths. I started learning to write summaries before I turned 11, and have continued to develop and refine those skills for 60 years. If you’re only 20 now and leave this task to your favourite AI, how long before your summarising skills fade away?
Of course the vendors of AI want your dependence on their products. For a modest $200 to $3,600 a year you can abandon most of your independent skills to Claude, ChatGPT or Grok. If that was investing in further development of your skills, I could see the sense in that. While there are plenty of substitutes for cognitive challenges and critical thought you’re getting AI to do, there’s no substitute for developing and maintaining your essential professional skills.
I’m not advocating that you should avoid AI altogether; there are times when it has its uses, and skilful use of any tool can always be turned to advantage. But if you write code, summaries or whole novels, you need to retain and develop your own skills alongside that. Like morphine, AI has great powers, but overused it can so readily become both addictive and destructive.
Login
