I wonder whether we’ll look back at 2024 as the year that Apple Intelligence came to our Macs and devices?

While there are plenty of nay-sayers, and those who still accuse Apple of falling behind, there can be few who aren’t aware of what’s available to those who have bought a recent Mac or one of the higher-end iPhones or iPads. Since Apple’s attempt to hijack the established abbreviation AI at WWDC last summer, we have heard little else. There can have been few minor updates that were sold as heavily as the autumn’s x.1 and x.2 releases for their lavishly preannounced new features.

We’ve been beta-testing some of those features for as long as we’re normally allowed for a whole major release of macOS. Over that period, the number of users who have switched to English (US) as their primary language must have been substantial. It’s the first time I have kept one of my Macs running beta-releases long after the annual macOS upgrade, and I only reverted when 15.2 was released with AI support for English (UK).

Although these AI features have their uses, and for many should prove quietly revolutionary, I’m not convinced that they transform our Macs or devices into anything even remotely intelligent, and a far cry from the great thinkers in Raphael’s masterpiece The School of Athens. The central figures here are Plato (left), who carries in his left hand a book titled TIMEO (I am afraid), and Aristotle (right), whose book bears the word ETICA (ethics). Seen further to the left in profile is Socrates, and below him is Pythagoras writing in a book while a boy holds in front of him a small blackboard showing the theory of harmony.

Contrast that hullabaloo about AI with Apple’s complete silence on security, specifically the changes brought in its front-line malware detection feature XProtect in macOS Sequoia, since its release on 16 September. Prior to that, XProtect’s data bundle, including its Yara file of detection signatures for malicious software, had been maintained by the general macOS update service through softwareupdated. The diagram below outlines this long-established process.

When Sequoia 15.0 was released, that changed to what has turned out to be an intermediate invoking both the old mechanism and the new.

For the first couple of weeks of that, XProtect updates were chaotic:

• 13 Sep (approx) Software Update Service stopped providing regular XProtect updates
• 13 Sep (approx) XProtect version 5273 available from Software Update Service for Sequoia only
• 16 Sep macOS 15.0 released, with version 5273 available from Software Update Service for Sequoia only; upgraded Macs updated to 5273 by copying from secondary to primary locations; 5273 not provided from iCloud, where 5272 remained the current version
• 18 Sep Software Update Service resumed delivery of 5272 to Sonoma and earlier
• 18 Sep Software Update Service started delivery of 5274 to Sonoma and earlier; 5273 no longer available for Sequoia, with 5272 still available from iCloud
• 24 Sep Software Update Service delivered 5275 for Sequoia; no change to Sonoma and earlier, and 5272 still available from iCloud.

Then, just as we were getting the hang of it, Sequoia 15.2 excised the old mechanism, as we discovered last week when Apple released the first update to XProtect since 15.2.

Throughout all of this, Apple has remained completely silent. What’s even more surprising is that in the last few days, Apple has updated its definitive guide to security for Macs and all its devices. Although not all localised English translations have yet been synced with its US or Canadian English versions, the account of XProtect now has a published date of 19 December 2024, but doesn’t mention September’s changes.

There are those who insist that none of this is our concern, we should just let Apple do whatever it deems appropriate, and we shouldn’t even know what version of XProtect’s data is installed, as macOS takes care of all that for us. However, the security of my Mac is very much my business. If I were to unwittingly install malware that stole sensitive information, those are my banking details at risk, not Apple’s. Should I suffer financial loss as a result, would Apple provide unlimited compensation?

Hardly. Read sections 8 and 9 of Apple’s licence for macOS Sequoia, and the onus is clearly placed on the user. Just to emphasise this, further down that licence, in the Apple Pay & Wallet Terms and Conditions, is the express statement: “You are solely responsible for maintaining the security of your Mac Computer, Supported Devices, your Apple Account, your Touch ID information, the passcode(s) to your device(s), and any other authentication credentials used in connection with the Services (collectively, your “Credentials”).” The next time someone says that you should leave the security of your Mac to Apple, remind them of that.

Apple also encourages us to take an active part in our Mac’s security protection, and provides us with tools for doing so. The description given in man xprotect is a good example: “xprotect is used to interact with XProtect. It is useful for administrators or users who want to manually invoke XProtect functionality.”

Information about XProtect updates is exposed in the GUI, in System Information, where each update including those delivered by both old and new mechanisms is listed, together with its version number. That in itself is puzzling, as recent entries incomprehensibly duplicate older XProtectPlistConfigData entries with newer XProtectCloudKitUpdates.

So if AI doesn’t bring us the School of Athens, what has macOS Sequoia achieved so far? For this second image I turn to Lovis Corinth’s first major painting after his near-fatal stroke just before Christmas in 1911, an autobiographical portrait expressing his frustrations, in The Blinded Samson from 1912.

Please don’t breathe a word of this over on Apple Support Communities, though, where it seems your Mac’s security should be like mediaeval religion, a matter of blind faith and the suppression of knowledge. It’s high time for a Renaissance, much more Enlightenment, and a modicum of Intelligence.

A few weeks ago I featured paintings of one of Boccaccio’s stories from his Decameron, retold in 1818 by the British poet John Keats (1795-1821) in his Isabella, or the Pot of Basil. Today’s article looks at paintings inspired by some of Keats’ other writings, and tomorrow those based on the works of Tennyson.

Keats completed and published his poem Endymion in 1818, when he was only twenty-three. This elaborates on the story of the shepherd of the same name who became the object of affection from the goddess Selene. However, instead of using her name, Keats used an alternative name for the goddess Artemis, who later became confounded with Selene.

George Frederic Watts’ painting of Endymion (1872) may well refer to Keats’ poetic reinterpretation, showing Endymion making love with the Titan goddess of the Moon, Selene. This is one of Watts’ most painterly works, and appears to have come straight from his emotions. This also marks his transition from painting Pre-Raphaelite staples such as mediaeval knights and legends, to his later works that were more allegorical if not frankly symbolist.

Edward Stott’s Trees Old and Young, Sprouting a Shady Boon for Simple Sheep from 1888 is unusual as it’s one of his few paintings with a literary reference, its title being a quotation from Endymion. However, its shepherdess is neither Endymion nor Selene/Cynthia.

The following year, Keats wrote the narrative poem The Eve of St. Agnes, which was published a year later, remains one of his finest works, and has formed the basis for at least three major paintings by Pre-Raphaelites.

Madeline has fallen in love with Porphyro, who is an enemy to her family. Older women have told Madeline that she can receive sweet dreams of love on the night of St. Agnes Eve, preceding the day on which the patron saint of virgins is celebrated, 21 January.

On that night, Porphyro gains entry to the castle where Madeline lives, and looks for Angela, who remains a friend to his family despite the feud. Angela reluctantly agrees to take him to Madeline’s room, so that he can gaze at her sleeping there. She takes him there, where he hides in a large wardrobe and watches her prepare for bed, seeing her full beauty in the moonlight.

He creeps out to prepare a meal for her, but she wakes, and seeing the same figure she had just been dreaming, takes him into her bed. She then wakes fully and realises her mistake. They declare their mutual love before escaping from the castle past drunken revellers, and flee into the night.

In this study for William Holman Hunt’s The Flight of Madeline and Porphyro During the Drunkenness Attending the Revelry from 1848, he shows the climax of the poem. Madeline and Porphyro, dressed in their cloaks, are creeping past the drunken bodies of those who have been at the feast. Through the arches at the left the drinking and feasting can be seen still in progress. In the foreground one of the revellers is clutching an empty cask of drink, while other remains of the drinking are scattered on the floor to the right. Two large dogs appear to be somnolent and not reacting to events.

Madeline’s face has a neutral expression, and she has her right arm across Porphyro’s chest to restrain him, her left hand in contact with his right hand on the hilt of his (smaller) sword, as if to restrain him from drawing it. Porphyro’s face shows tension, almost amounting to anger, perhaps, as his left hand holds a door behind him, at the right edge of the painting. That door bears a key, suggesting it’s an outer door. His right hand grips the handle of his sword, as if about to draw it.

Instead of Holman Hunt’s elaborate and ingenious composition, Arthur Hughes opts for a triptych, read from left to right. At the left, Porphyro is approaching the castle. In the centre, he has woken Madeline, who has not yet taken him into her bed. At the right, he almost quotes from Holman Hunt’s version, showing the couple’s escape over drunken revellers. There is also a second, undated version in the Ashmolean, Oxford, in which the painting at the left shows a slightly later moment, where Porphyro meets Angela at the entrance to the castle.

Hughes felt the need to provide the viewer with an excerpt of the original text:
They told her how, upon St Agnes’ Eve,
Young virgins might have visions of delight,
And soft adorings from their loves receive
Upon the honey’d middle of the night.
If ceremonies due they did aright,
And supperless to bed they must retire,
And couch supine their beauties lily white,
Nor look behind, nor sideways, but require
Of heaven with upward eyes for all that they desire.

This painting was very well received when shown at the Royal Academy in 1856, with the critic John Ruskin and painter Dante Gabriel Rossetti being enthused by it.

John Everett Millais’ The Eve of St Agnes from 1863 is one of the few Pre-Raphaelite paintings to have been purchased by the British Royal Collection: despite the great achievements of the movement, their works were not favoured by Queen Victoria.

This shows Madeline completing the rituals prescribed for the night, as she prepares to undress for bed, in verses 25-26 of Keats’ poem:
Full on this casement shone the wintry moon,
And threw warm gules on Madeline’s fair breast,
…her vespers done,
Of all its wreathed pearls her hair she frees;
Unclasps her warmed jewels one by one;
Loosens her fragrant boddice; by degrees
Her rich attire creeps rustling to her knees:
Half-hidden, like a mermaid in sea-weed,
Pensive awhile she dreams awake, and sees,
In fancy, fair St. Agnes in her bed,
But dares not look behind, or all the charm is fled.

This curiously static scene from an action-packed narrative was painted from life: Millais used the King’s Bedroom in the Jacobean house at Knole Park, near Sevenoaks in Kent, with his wife Effie as his model. The special bull’s eye lantern producing the eerie lighting effect was a detail over which he took meticulous care. The end result is another evocative, sensual painting that’s almost devoid of narrative.

Before The Eve of St. Agnes was published, Keats wrote La Belle Dame Sans Merci, a ballad about a femme fatale, derived in part from a fifteenth century poem by Alain Chartier. This concerns a fairy who seduces a knight with her eyes and singing, then condemns him to an unpleasant fate. It was published in its original version in 1819, and in a revised version in 1820. It includes the the verses

I met a lady in the meads,
Full beautiful, a fairy’s child;
Her hair was long, her foot was light,
And her eyes were wild.

I made a garland for her head,
And bracelets too, and fragrant zone;
She looked at me as she did love,
And made sweet moan.

I set her on my pacing steed,
And nothing else saw all day long,
For sidelong would she bend, and sing
A faery’s song.

Walter Crane is one of the earlier artists to represent this in a painting, with subsequent similar depictions by Arthur Hughes and Frank Dicksee. The ‘belle dame’ of the title is shown riding side-saddle on the knight’s horse, flowers in her long, flowing tresses, and the knight clad in armour and heraldic overgarments, holds her hand.

Early in 1821, when he was only twenty-five, John Keats died of the complications of tuberculosis.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Comfort for the organ cabinet and shows entries from 2.

2: Mass of wood measures a ship’s speed for the jottings of your Mac.

3: Guide points the way to measure performance in 2.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

System logs seem to have been introduced with Mac OS X in 2000-2001, and I don’t recall any equivalent in Classic Mac OS, although individual apps such as databases often kept their own logs.

2000-2016 text logs

As Mac OS X presented itself as a derivative of Unix, it brought with it bells and whistles such as support for code to write to system-level logs including system.log, console.log and dozens of other more specialist destinations, and its own log browser in the Console app.

As is traditional, log entries contained unstructured plain text to which a datestamp and other data were added to expand each into a line of text in log files that were rotated daily. As entries were relatively infrequent, many users learned to read the log and to use it to diagnose problems.

The Console app gave ready access to all standard logs as well as app-specific ones, such as this for mail processes such as sendmail, and crash reports. These two screenshots are from Mac OS X 10.0 Cheetah in April 2001.

By Mac OS X 10.4 Tiger in 2005, Console had acquired some basic tools and a sidebar to select from the many logs. Because they were plain text, those for previous days were compressed and stored in archives until they were removed during routine housekeeping. This excerpt shows entries in the system log over a restart that took over 2 minutes from the last entry to the start of the boot process.

There has also been the rare substitute for Console: this is LogMaster from Bright Light Software, shareware for $14.50 in 2006 until it was abandoned.

Although much in Console remained the same until 2016, at some stage Apple structured log entries into fields, as shown here in Mac OS X 10.6 Snow Leopard. Log entries were still infrequent, with this excerpt covering a period of almost 20 seconds.

This is another restart, here in OS X 10.10 Yosemite in April 2015. This time, the period recorded for that restart has fallen to 39 seconds. System shutdown is marked by the shutdown process and SHUTDOWN_TIME, and startup begins with BOOT_TIME.

2016 Unified log

With macOS Sierra in 2016, that was all swept away and replaced by the Unified log. There had been warning signs that change was coming: in May of that year, I complained that the log consisted of a torrent of messages like
17/05/2016 21:04:40.175 storeassetd[531]: multibyte ASN1 identifiers are not supported.
or
17/05/2016 20:55:15.298 WindowServer[233]: _CGXRemoveWindowFromWindowMovementGroup: window 0x91 is not attached to window 0x92
Even when running a fairly clean installation of El Capitan, All Messages clocked up around 4000 entries every 8 or 9 hours. At its worst, the log could fill those 4000 message slots in a minute or two. Little did we realise how busy our logs were about to become.

Apple declared the goals of its new log system at WWDC in June 2016:

• a single efficient logging mechanism for user and kernel mode;
• to maximise information collection with minimum observer effect;
• the compression of log data;
• a managed log message lifecycle;
• as much logging on as much of the time as possible;
• for privacy to be designed into the logging system;
• a common system across macOS, iOS, watchOS, tvOS;
• all legacy APIs (NSLog, asl_log_message, syslog, etc.) to be redirected into the new unified log;
• to emphasise debugging of macOS and apps, not providing any facilities for system administration or audit;
• to link to the sysdiagnose tool for gathering information for bug reports etc.

To achieve this, a log entry is made using a new call that’s handled by the logd daemon and compressed into a buffer. From there it’s either retained in memory if ephemeral, or written out to a file.

There are two main groups of files that store log entries: those kept in /var/db/diagnostics/Persist/ in the form of tracev3 files containing regular log entries, and further tracev3 files in /var/db/diagnostics/Special/ containing additional shorter-life entries. Additional and lengthier log data can be stored in files named by UUID in /var/db/uuidtext/, and there’s also scope for high-volume collection.

tracev3 files use a proprietary compressed binary format that remains undocumented to this day, but has been partially reversed. Apple doesn’t provide direct access to their contents, only through closed-source utilities such as the log command tool. Where users want a more portable format, Apple recommends conversion to a logarchive package, although that’s also undocumented and only directly accessible using log and Console. Apple has in recent years given limited access to the active log for third-party apps, but that lacks many of the useful features of its own log command.

Privacy

Privacy features have caused problems from the start. Log messages containing potentially sensitive information have that censored by <private>. Like so many good ideas, this had unintended consequences as many log entries only contain the dreaded <private>, and in some cases meaningful content is lost altogether.

Ironically, the most embarrassing security problem in the Unified log occurred in early versions of High Sierra, when encryption passwords were leaked apparently as a result of incorrect string formatting. Apple subsequently added an entry field to make explicit the formatting used for that entry.

Until the release of Catalina, there was an undocumented switch to turn privacy protection off, through an option to the log config command. When you needed to view all those censored messages, you could turn protection off, perform the test, and the log then contained all the information you required. That changed in Catalina 10.15. In order to bypass this privacy protection, you had to run your Mac in a special diagnostic mode intended for use exclusively by Apple engineers. Apple later relented and allowed this to be controlled through a profile, although because entries already made don’t contain the censored data, it can’t be applied retrospectively.

When first released, access to the new Unified log wasn’t restricted to admin users, but that changed in macOS 10.12.4, when that restriction was applied, and normal users found they were no longer able to browse the log at all.

Problems

The biggest disappointment, though, has been the Console log browser, which has made only limited use of log entry structure, displays just a small selection of entry fields, provides little aid for the high volume of entries, and worst of all gives no access at all to recent entries in the live log. Apple’s decision to restrict Console to browse the live stream of entries and logarchives has rendered it useless for many of the most compelling reasons for the app, but it has ensured that Console and the log provide no “facilities for system administration or audit”. It has also deterred third-party developers from writing to the log, and made it the exclusive preserve of Apple’s engineers, which perhaps was the original intention.

Since its first release in macOS Sierra, the log has flourished if not grown like an invasive weed. The number of fields available has increased from 16 to over 25, many of them added to support Signposts, introduced in late High Sierra and Mojave. Those are used extensively in macOS primarily to measure performance.

As the log now rolls its tracev3 files to maintain a maximum total file size, rising rates of entries by macOS have limited the period covered by retained entries. What in the early days was sufficient for up to 20 days of entries may now last little longer than a few hours. This also ensures that Console has more limited usefulness, and it struggles to cope with logarchives of any size.

Collection and retention of entries from different subsystems is set in logging profiles, XML property lists stored in /System/Library/Preferences/Logging (in the System volume, so read only) and /Library/Preferences/Logging, which the user controls. You can create your own custom profiles, or modify them on the fly using the log command, although this appears unusual even among the few left who can and do still browse the log.

What used to be a primary tool in diagnosing problems has been abducted without replacement. At least it keeps those pesky system administrators and auditors away.

Separation of living from sleeping accommodation has become increasingly popular in most societies as they have become more affluent and housing has become more spacious. In its extreme, among the wealthy, bedrooms have acquired supplementary areas for dressing and personal grooming, leaving the bedroom itself dedicated to the bed and sleep. For that it’s usually the most private room in a house or apartment.

Emmery Rondahl’s Doctor’s Orders (1882) shows a Danish country doctor writing a prescription for an older patient who is tucked up in a magnificent fitted bed in their own home. Although still a humble dwelling, with an uneven and uncarpeted stone floor, the bed has luxuriant curtains and there’s even a short net curtain at the window.

Edgar Degas’ famously enigmatic Interior from 1868-69 remains fascinating even if you ignore its two figures. The woman’s outer clothing is placed at the foot of the bed, and her corset has been hurriedly or carelessly cast onto the floor beside it. Just behind her is a small occasional table, on which there is a table-lamp and a small open suitcase. Some of the contents of the suitcase rest over its edge. In front of it, on the table top, is a small pair of scissors and other items from a small clothes repair kit or ‘housewife’.

The man’s top hat rests, upside down, on top of the cabinet on the far side of the room, just in front of the woman. Despite the obvious implication that they are a couple who have met in that room to engage in a clandestine sexual relationship, the bed is a single not a double. It also shows no sign of having been used, nor has the bedding been disturbed in any way.

There’s a mature fire burning in the fireplace behind the woman and the lamp. There are four paintings or similar objects hanging on the walls, of which only one appears to be decipherable. This is the large rounded rectangular one above the fireplace. Although it appears to be a mirror, the image shown on it doesn’t resemble a reflection of the room’s interior, but looks to be a painting. This might show a bright figure, resembling the woman, in front of some shrubs, with classical buildings behind.

A few years later, in 1876-77, probably when Degas was starting his series depicting women drying themselves after they had bathed, he painted a woman in pastel over a monotype, where the figure is set in the broader context of a bedroom, in Woman Drying Herself after the Bath. This is a plain and simple bedroom, with a single bed and a dressing table with a mirror. Other paintings in this series are closer cropped on the woman.

Morning, Interior (1890) is one of Maximilien Luce’s best-known Divisionist paintings from the late nineteenth century. This is a humbler bedroom situated in the uppermost part of the house, a garret perhaps, his dressing table lacks a mirror, and the bed is a lightweight folding model with a thin mattress.

Before the end of the century, Pierre Bonnard had started painting the intimate interiors that were to dominate his art for much of the rest of his life. Few, though, depicted the bedroom he shared with his partner Marthe.

In 1898, Bonnard painted the first of his controversial works revealing his private life with Marthe, in Man and Woman in an Interior. He stands naked, looking away, as Marthe is getting dressed on the bed. He has also cropped this unusually, as if it was a ‘candid’ photo, enhancing its voyeurism.

Félix Vallotton’s disturbing domestic scenes continued with Interior, Bedroom with Two Figures from 1904. The lady of the house is standing, her back to the viewer, over her maid as the latter is sewing up an evening gown for her. The lady’s face is revealed in her reflection in the large mirror on the wardrobe at the back of the room, where her maid is all but invisible.

John Collier followed Degas’ enigmatic interiors with Mariage de Convenance from 1907. A mother, dressed in the black implicit of widowhood, stands haughty, her right arm resting on the mantlepiece of her daughter’s bedroom. The latter cowers on the floor, her arms and head resting on her bed, in obvious distress. Laid out on the bed is the daughter’s wedding dress, the crux of this painting’s riddle.

Édouard Vuillard’s portrait of Lucy Hessel Reading in her bedroom from 1913 needs more context. Lucy was the wife of the art dealer Jos Hessel (1859-1942), and she was a frequent model, companion and long-term lover of Vuillard. At this time, her husband was Vuillard’s sole dealer.

Just before the Second World War, Eric Ravilious painted a series of contemporary and deserted bedrooms.

The Bedstead (1939), with its wide angle projection, is full of patterns: the wallpaper, floorboards and rugs, and features a mass-produced iron bedstead.

In his Farmhouse Bedroom (1939) the patterns are overwhelming, and its projection has become so extreme that it distorts.

Apple provides so many services for different parts of macOS that it’s hard to keep track of them. If you want to see a short summary, this article lists all service connections for enterprise network administrators, although it doesn’t detail which services use which servers, for example referring to “macOS updates” in many entries.

Many of you seem surprised to learn that Sequoia’s new XProtect updates come from iCloud, although Apple has been using iCloud for similar purposes for at least the last five years.

One good example that’s used every day on your Mac are the notarization checks sometimes run by Gatekeeper when macOS launches executable code, such as an app. In that case, com.apple.syspolicy processes the app’s notarization ticket
looking up ticket: <private>, 2, 1
by trying to fetch its record from iCloud using CloudKit. That’s followed by log entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy in
CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups. I first reported those checks with iCloud back in Catalina, in 2019.

A simple way to illustrate the differences between this and using the general softwareupdated service is to compare what happens in the log when you ask if there are any updates available.

softwareupdate

When SilentKnight does this, it uses the only supported method, the softwareupdate tool, as used to keep XProtect up to date in all versions of macOS prior to Sequoia. That command hands over to the softwareupdated service to run the check. That in turn uses components of com.apple.SoftwareUpdateController to summarise the update state of that Mac, connect to the Software Update Server, check all the current versions and build numbers of macOS and its ancillaries, and arrive at a list of updates required. This is even more complex than it sounds, as com.apple.SoftwareUpdateController has to check key settings such as whether the root volume is sealed or not.

You can trace this through several thousand log entries, and after around 4.4 seconds and multiple network connections, softwareupdate finally informs SilentKnight that there are no updates available.

xprotect

Running the command
sudo xprotect check
in Sequoia is far simpler and quicker, as it checks for just one component’s updates through iCloud. The command connects to XProtectUpdateService in the XprotectFramework private framework in macOS, which in turn fires up CloudKit to connect to iCloud. That fetches a database record and returns the result to XProtectUpdateService, and so back to the xprotect tool as its result. Total time taken is 0.5 second.

As Apple’s intent in changing the management of XProtect and its data appears to be to facilitate more frequent and macOS-specific updates, iCloud is an ideal platform to host this on.

Pinniped with tusks

There is, though, one last thing: what is the walrus? As that might seem an odd question, read these two log entries encountered when browsing what happened with the xprotect check command:

12:08:00.919841 com.apple.cdp XPC Error while fetching walrus status: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process.}
12:08:00.919845 com.apple.cloudkit CoreCDP reports that walrus is undetermined for the logged in account. Error: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}

The prospect of an undetermined walrus that can’t be fetched from inside my Mac might seem worrying

This second collection of paintings that were made one hundred years ago, in 1924, opens with some narrative works, followed by a couple of interiors, miscellaneous works, and ends with an early sporting painting.

Lovis Corinth’s Trojan Horse proved to be his last major painting from classical myth, showing the wooden horse made by the Greeks to gain access to the city of Troy so they could destroy it. The city is seen in the background, with its lofty towers and impregnable walls. The select group of Greek soldiers who undertook this commando raid are already concealed inside the horse, and those around it are probably Trojans sent from the city to check it out.

Although there are suggestions of an allegorical relationship between this painting and the First World War, Troy had been a hot topic in Berlin since the excavations at Hisarlık in Turkey in the late nineteenth century by Heinrich Schliemann and Wilhelm Dörpfeld.

Ker-Xavier Roussel’s Sleeping Diana uses a simpler motif of the goddess asleep under the watchful eye of one of her devotees, as a deer comes to drink at the pool between them.

Kazimierz Sichulski’s Bacchanal shows three naked bacchantes cavorting with Bacchus. This is set during the grape harvest, with bowls of the fruit and a couple of donkeys laden with buckets for the crop.

Mykola Ivasyuk’s Riders on the Steppe is one of this Ukrainian artist’s late Cossack paintings. Two years later, Ivasyuk was appointed professor at the Kyiv Art Institute, but started to fall out of favour and was transferred to Odesa, where criticism became more serious. In the autumn of 1937, he was arrested, imprisoned, convicted of being a terrorist on the basis of his art, and was shot by a firing squad in Kyiv on 25 November 1937. Much of his art was confiscated or destroyed, and it wasn’t until 1980 that he was rehabilitated and his surviving paintings could be seen again.

In Édouard Vuillard’s Reading in the Dining Room, Vaucresson, Lucy Hessel has already left her husband Jos reading the newspaper at the breakfast table, and gone to busy herself in the next room. Behind this mundane domestic scene is deeper complexity: Jos and Lucy Hessel were close friends of the artist, so close that at the time of this painting Vuillard, then in his mid-fifties, and Lucy were lovers.

Until relatively recently, Icelandic society remained strongly traditional, and homes in its capital Reykjavik were still decorated in older style. Þórarinn Þorláksson’s glimpse into The Artist’s Home shows this well.

I believe that Henri Le Sidaner’s White Garden at Dusk shows a corner of the artist’s garden in the old village of Gerberoy.

The pioneer Swedish natural history painter Bruno Liljefors never lost his fascination for the relationship between predators and prey, as seen in his Sea Eagles Chasing an Eider.

By the early years of the twentieth century, circuses were an established if itinerant part of society. Children in neighbourhoods engaged in circus games, as shown so delightfully in Heinrich Zille’s lithograph Circus Games.

When Charles Demuth was unwell as a result of his diabetes he sought solace in floral paintings, such as these exquisite Fruit and Sunflowers.

Lovis Corinth sometimes painted purely for fun: this superb depiction of a Königsberger Marzipantorte (Royal Marzipan Cake) must have been completed at speed before his family consumed the model.

The American artist George Bellows is perhaps best-known for his paintings and prints of boxing matches, many of them clandestine. Dempsey and Firpo, though, shows a famous historic boxing match between the heavyweights Jack Dempsey, world champion since 1919, and Luis Ángel Firpo, an Argentinian challenger. This took place in the Polo Grounds of New York City on 14 September 1923.

From the start of the first round, the fight was gripping in excitement, with Dempsey knocking Firpo down seven times. Towards the end of the first round, Dempsey was trapped against the ropes, and Firpo knocked him out of the ring, the moment shown here. Dempsey finally knocked Firpo out late in the second round. This was made from contemporary press photographs.

If your Mac is running macOS Sequoia version 15.2 and you keep an eye on its security data updates, you may have noticed that those have changed again. Perhaps the only way to make sense of what has happened is to understand how XProtect updates work in recent versions of macOS.

Before doing that, there are two important issues to make clear:

• Despite their names, XProtect and XProtect Remediator are different, and in Sequoia are updated using different mechanisms. XProtect is run on-demand when macOS is about to execute code, while XProtect Remediator runs scans for malware in the background about once a day. This article is only about how XProtect updates, as XProtect Remediator is still updated using the softwareupdate mechanism, and that hasn’t changed.
• Sequoia obtains XProtect updates through a connection to iCloud that is independent of whether your Mac is logged into your Apple Account in iCloud. So long as your Mac is connected to the internet and nothing blocks its iCloud connections, those updates will be available to it, regardless of whether it’s connected to your Apple Account or iCloud Drive. This is in common with other services that macOS relies on, such as making notarization checks on apps, and updating linguistics data and those used by AI.

macOS Sonoma and earlier

Like other security data updates including XProtect Remediator, XProtect is updated through Software Update, or the command tool softwareupdate, which is how SilentKnight obtains its updates too. Shortly after starting up, and at least daily after that, your Mac’s softwareupdated service contacts Apple’s software update servers and checks whether there are any updates available. If there are, they’ll be automatically downloaded and installed, provided that’s enabled in System Settings.

In this case, XProtect is installed in its traditional place, in /Library/Apple/System/Library/CoreServices as XProtect.bundle.

mcOS Sequoia 15.0-15.1.1

For this brief period, XProtect updates have been available using either of two methods.

The traditional method using Software Update or softwareupdate continues to install the XProtect bundle in its old location, where it could still be used, but the XProtect service in Sequoia expects to find it in a different location, in /private/var/protected/xprotect, where it’s still known as XProtect.bundle.

The new method installs the XProtect bundle directly into its new location, and doesn’t obtain it using Software Update or softwareupdated, but an undocumented service that connects to iCloud instead. That appears to activate at least once a day, independent of softwareupdated, and silently checks for XProtect updates in iCloud. When it finds one, that’s installed directly to /private/var/protected/xprotect but not the traditional location in /Library/Apple/System/Library/CoreServices. It’s therefore perfectly possible for the two XProtects to get out of sync, although the only one that Sequoia uses is that stored in the new location.

Sequoia also introduces a new command tool xprotect to help manage these new updates. If you run
sudo xprotect update
and the version of the XProtect bundle in the traditional location is greater than that in the new location, then the newer version will be copied to the new location to install it there as an update, instead of having to wait for the update through the new iCloud mechanism. This also provides redundancy, but relies on the two sources providing identical updates.

To add a final twist of confusion, if xprotect copies the XProtect bundle from the traditional to the new location, it does so by copying its contents, so its version number changes but the bundle itself retains its previous date of creation and modification, which can prove thoroughly confusing. The lesson here is to check the bundle by its version number, not by its dates.

macOS Sequoia 15.2 and later

In the latest release of Sequoia, the traditional method of updating XProtect is no longer used. If softwareupdate were to download and install an update, then it will only end up in the traditional location, and xprotect update can’t use that to update the new location.

In normal use, this means that the user can’t update XProtect until that new version is made available from iCloud. This ensures that the only versions provided to Macs running 15.2 and later are those intended to be used in Sequoia, but it also means that any delay in providing those via iCloud will leave Macs without the latest update.

Apple has modified the xprotect command to provide one let-out, though: use
sudo xprotect update --prerelease
and it “will attempt to use a prerelease update, if available.” Note that still can’t use a traditional XProtect update installed in the traditional location, and still has to be able to obtain the update from iCloud, but it might work when xprotect check and xprotect update can’t offer a new update yet. Note that Apple describes that early-bird version as prerelease, and it shouldn’t therefore be used as if it’s a regular release, and only for good reasons.

SilentKnight

Because of these changes, as of Sequoia 15.2, SilentKnight is no longer able to provide any assistance in updating XProtect, and its next version 3.0 will also be unable to do anything more useful than inform you that your current version of XProtect is up to date, or out of date. If it is out of date, then it’s up to you what you decide to do about it. In most cases, that should be to leave well alone and let macOS handle the update as it’s intended to.

Because time of release of XProtect updates through softwareupdate and iCloud differ, and vary around the world, availability from one source is no guarantee that the other will also be offering that update. For example, on 17 December, the softwareupdate version became available by about 1830 GMT. A prerelease version for 15.2 was available several hours before that, but the regular release wasn’t available from iCloud until early the following day. If Apple is intending to fork XProtect data for 15.x from those for older versions of macOS, the two update services will be offering quite different bundles anyway, as we experienced briefly in the early days of Sequoia.

Although I do periodically poll traditional softwareupdate servers for new updates, repeatedly doing so for iCloud updates doesn’t appear a good way to proceed, and could in any case be misleading. On the other hand I don’t think it’s intended that apps like SilentKnight should check for prerelease updates as a matter of course, and abuse of that option could lead to its removal. In other words, Apple wants full control over when your Mac can and will update to new versions of XProtect, presumably because Sequoia will be getting different updates in the future.

Summary

• If your Mac hasn’t been upgraded to Sequoia, XProtect updates continue as usual, and SilentKnight will continue to be able to find and install them as it has done in the past.
• If your Mac is running Sequoia 15.0 to 15.1.1, then it will continue to be offered XProtect updates both ways, and should continue to do so until you update it to 15.2.
• Macs running 15.2 and later now get XProtect updates differently. Neither you nor SilentKnight can alter that, unless you want to try obtaining prerelease updates through the xprotect command in Terminal. While SilentKnight and Skint will warn you when an XProtect update is expected, you should rely on macOS to handle those updates for you.

Ask anyone who has lived in the country and they’ll recall its idyllic moments. To end this series, I celebrate a few of those in paintings from the turn of the nineteenth to twentieth centuries.

This Ukrainian farm labourer is caught relaxing for a moment in the sun and flowers of early summer in Mykola Kuznetsov’s early In Celebration (1879-81).

The pair of ploughmen in Giovanni Segantini’s Ploughing may not have had time to study the fine mountain views near the Alpine village of Savognin, but they and the other labourers in the right distance are enjoying the fine weather.

A couple of years later, Segantini’s High Noon in the Alps (1892) catches this shepherdess enjoying a brief break in her work, in the intense summer sunshine of the high plateau.

Pascal Dagnan-Bouveret shows that even itinerant workers could sit together and eat to the music of a violin when living In the Forest in 1893. Behind them are two oxen, and the forest that’s currently their home.

In Poland, Teodor Axentowicz’s painting of Oberek Folk Dance in Front of a House from 1895 shows locals dancing the second most popular Polish folk dance after the polka. Most of these dancers are barefoot.

Edward Stott’s shepherd has stolen a moment of Peaceful Rest as his small flock drinks from a pond. He’s lighting a clay tobacco pipe, with his crook resting on his leg. Most of the painting uses a limited palette, with three splashes of colour standing out: the man’s face lit by the flame, the watchful sheepdog behind him, and a blue object protruding from the man’s jacket pocket.

Jules Bastien-Lepage’s Love in the Village shows a young couple on either side of a tumbledown fence, chatting intimately among the vegetable patches.

Idyllic moments indeed, but what happens in the country is often a far cry from the town.

Nikolai Astrup’s humorous painting of Early Courting from 1904 shows a young couple at the far left engaged in ‘clothed courting’ in the unromantic surroundings of a cowshed. He has a bottle of drink in his pocket; whether that’s to give him courage or to weaken the resistance of his girlfriend is unclear.

The couple have sought the privacy of the cowshed, out of everyone’s way, but the boyfriend appears unaware that they’re being watched by someone up in the roof. From the apparent direction of gaze of the girlfriend and the blush on her cheeks, she has just noticed the peeping tom or watchful relative. The setting is enhanced by the sunlight pouring through the far window, illuminating two rows of the back-ends of cows. The wood floor between the cows appears to be decorated with small sketches, but those are actually piles of cow dung. Courting in the country must have been a sensorily rich experience.

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. This article considers how true that might be, and what benefits there might be to using faster solid-state storage.

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. These 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:

• 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 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 throttling 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.

Performance checks

Before each Time Machine backup starts, backupd runs two checks of disk performance, by writing one 50 MB file and 500 4 KB files to the backup volume, reported in the log as
Checking destination IO performance at "/Volumes/ThunderBay2"
Wrote 1 50 MB file at 286.74 MB/s to "/Volumes/ThunderBay2" in 0.174 seconds
Concurrently wrote 500 4 KB files at 23.17 MB/s to "/Volumes/ThunderBay2" in 0.088 seconds

With normal throttling in force, there’s surprisingly wide variation that appears only weakly related to underlying SSD performance, as shown in the table below.

Results from the three first full backups are far greater than those for subsequent automatic backups, with single-file tests recording 900-1100 MB/s, and multi-file tests 75-80 MB/s. Routine backups after those ranged from 190-365 MB/s and 3-32 MB/s, less than half. Most extraordinary are the results for the OWC Express 1M2 enclosure when used with an M3 Pro: on the first full backup, the 50 MB test achieved 910 MB/s, but an hour later during the first automatic backup that fell to 191 MB/s.

Evidence suggests that in macOS Sequoia, at least, first full backups may now run differently, and make more use of P cores, as shown in the CPU History window above. In comparison, automatic backups are confined to the E cores. However, the backup itself still runs at a tenth of the measured write speed of the SSD.

Time Machine runs the first full backup as a ‘manual backup’ rather than scheduling it through the DAS-CTS dispatching mechanism. It’s therefore plausible that initial backups aren’t run at a Background QoS, so given access to P cores, and at a higher I/O throttling policy than IOPOL_THROTTLE, so being given higher priority access to I/O.

Changing policy

When tested here previously, disabling throttling policy appeared to have little effect on Time Machine’s initial performance checks, but transfer rates during backups were as much as 150% of those achieved when throttling policy was in force.

The big disadvantage of completely disabling throttling policy is that this can only be applied globally, so including I/O for Spotlight indexing, file synchronisation, other background tasks and 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.

SSD or hard disk?

Despite wide variation in test results, all those for the 50 MB file were far in excess of the highest write speed measured for any equivalent hard disk at 148 MB/s (for the outer disk). Overall backup speeds for the first full backup to a USB4 SSD were also double that hard disk write speed. When throttling does occur, the period of sleep enforced on writes to a hard disk is eight times longer than that for an SSD, making the impact of I/O throttling greater for a hard drive than an SSD.

Another good reason for preferring SSD rather than hard disk storage is the use of APFS, and its tendency over time to result in severe fragmentation in the file system metadata on hard disks. Provided that an SSD has Trim support it should continue to perform well for many years.

Conclusions

• macOS applies throttling policies on I/O with both local and networked storage to ensure that I/O-intensive tasks like backing up don’t block higher priority access.
• Disabling those policies isn’t wise because of its general effects.
• Those policies use different settings for I/O to SSDs from those for other types of storage to allow for their different performance.
• First full backups to SSD appear to run at higher priority to allow them to complete more quickly.
• As a result, effective write speeds to SSDs during Time Machine backups are significantly faster than could be achieved to hard disks.
• When the consequences of using APFS on hard disks are taken into account, storing Time Machine backups on SSD has considerable advantages in terms of both speed and longevity.

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5284, and to XProtect Remediator for all macOS from Catalina onwards, to version 149. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect augment existing rules for dylibs in MACOS.ADLOAD, and add 2 new rules for MACOS.DOLITTLE, 1 for MACOS.PIRRIT, 5 for MACOS.BUNDLORE and 5 for MACOS.ADLOAD.

XProtect Remediator adds a new scanner module for Bundlore. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and later).

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, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-149 and XProtectPlistConfigData_10_15-5284.

For Sequoia 15.2 and later only: XProtect updates are no longer supplied through Software Update, softwareupdate, or SilentKnight. The only way that your Mac can obtain XProtect updates is through a connection to iCloud, which is supposed to happen automatically. If your Mac hasn’t yet been updated to version 5284, you can try using the Terminal command
sudo xprotect update --prerelease
(with a double hyphen not an m-dash)
That should download and install this update even though it hasn’t yet been generally released through iCloud.

For Sequoia 15.1.1 and earlier only: this update hasn’t yet appeared in iCloud, which may still return an XProtect version of 5283. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

[Updated blind-guessing the changes in 15.2, at 2030 GMT 17 December 2024.]

The association between two plants, holly and ivy, with the feast of Christmas appears peculiarly British, and best expressed in the traditional carol The Holly and the Ivy. Apparently, holly has been a symbolic reference to Jesus Christ since the Middle Ages, now explained by its red berries representing the drops of blood of the crucifixion, and the crown of thorns worn by Jesus. Ivy then forms a symbolic reference to Christ’s mother, the Virgin Mary.

This is seen in cameo in two paintings by British artists of the nineteenth century.

Dante Gabriel Rossetti painted a couple of works on and about Christmas, of which A Christmas Carol from 1867 is probably the more interesting. His model is Ellen Smith, described as a ‘laundry girl’, who is dressed in items from the artist’s collection. There are several allusions to Christmas, particularly the Virgin and Child just above the model’s face, and a sprig of holly with its red berries at the end of her musical instrument.

Sophie Gengembre Anderson’s undated Christmas Time – Here’s The Gobbler! includes a larger spray of holly on the wall at the top right.

Otherwise, holly is only exceptionally identifiable in paintings, and the only reference I have found is in a single work by James Tissot, where it appears together with ivy, but not in reference to Christmas.

Tissot painted The Farewells soon after his flight to London following the Franco-Prussian War and Paris Commune. This couple, separated by the iron rails of a closed gate, are in late eighteenth century dress. The man stares intently at the woman, his gloved left hand resting on the spikes along the top of the gate, and his ungloved right hand grasps her left. She plays idly with her clothing with her other hand, and looks down, towards their hands.

Reading her clothing, she is plainly dressed, implying she is perhaps a governess. A pair of scissors suspended by string on her left side would fit with that, and they’re also symbols of the parting taking place. This is reinforced by the autumn season, and dead leaves at the lower edge of the canvas. However, there is some hope if its floral symbols are accurate: ivy in the lower left is indicative of fidelity and marriage, while holly at the right invokes hope and passion.

Ivy has longer and more extensive traditions throughout European painting, although it too is only exceptionally identifiable.

In mythology, a thyrsus or thyrsos is a form of staff or even spear decorated with plant matter. In its strictest form, it should be a wand made from the giant fennel plant, decorated with ivy leaves and tipped with a pine cone or artichoke. It’s almost invariably an attribute of the god Dionysus (Roman Bacchus), and his devotees, maenads or bacchantes. It’s thus associated with prosperity, fertility and their over-indulgence in the form of hedonism. In the extreme, it can be tipped with a metal point and used as a club.

Annibale Carracci’s Triumph of Bacchus and Ariadne (1597-1602) is a marvellous fresco on a ceiling in the Palazzo Farnese in Rome. Dionysus is sat in his chariot with his thyrsus, here a long staff wound with ivy leaves but without any tip. Although a feature of many other paintings, this is one of very few decorated with ivy.

Ivy also makes an appearance in a not dissimilar painting with open narrative, this time by Philip Hermogenes Calderon in 1856.

Calderon’s Broken Vows is an early ‘problem picture’. A beautiful young woman, displaying her wedding ring, stands with her eyes closed, clutching a symbolic ‘heart’ area on her chest to indicate that her love life is in trouble. On the ground near the hem of her dress is a discarded necklace or ‘charm’ bracelet. The ivy-covered wall behind her would normally indicate lasting love, which was her aspiration.

A set of initials are carved on the fence, and on the other side a young man holds a small red flower in front of his forehead, which a young woman is trying to grasp with her right hand. The wooden fence appears tatty, and has holes in it indicating its more transient nature, and affording glimpses of the couple behind, but only tantalisingly small sections of their faces.

Calderon here deliberately introduces considerable ambiguity. The eyes of the shorter person behind the fence are carefully occluded, leaving their gender open to speculation. Most viewers are likely to conclude that the taller figure behind the fence is the unfaithful husband of the woman in front, but that requires making assumptions that aren’t supported by visual clues. Whose vows are being broken? Calderon invites us to speculate.

Like laurel, ivy can also be worked into a crown.

Francisco Pradilla’s watercolour of A Flute Player Crowned with Ivy is a delightful example from 1880. But it took Pierre Puvis de Chavannes to envisage ivy being used instead of a length of rope.

In Puvis’ Fantasy from 1866, one of the two people in this idyllic wooded landscape is using a length of ivy to school a winged white horse, either Pegasus or a hippogriff.

Although seldom clearly identifiable in landscape paintings of trees, one of Paul Nash’s last conventional landscapes is an exception.

Oxenbridge Pond from 1927-28 shows a pond at Oxenbridge Farmhouse, Iden, not far from the artist’s home. Patterns of brushstrokes are assembled into the textures of foliage, ivy covering a tree-trunk, even the lichens and moss on the trunk closest to the viewer, at the right edge.

Reference

Wikipedia on the carol The Holly and the Ivy.

When running apps on Intel Macs, because all their CPU cores are identical, the best you can hope for is that tasks make use of the number of cores available by running in multiple threads. Even single-threaded processes running on Apple silicon Macs get a choice of CPU core type, and this article explains the limited control you have over that.

In my current model of CPU core allocation by macOS, shown in part above, Quality of Service (QoS) is the factor determining which core type a thread will be allocated to. QoS is normally hard-coded into an app, and seldom exposed to the user’s control.

If a thread is assigned a minimal QoS of Background (value 9), or less, then macOS will allocate it to be run on E cores, and it won’t be run on a P core. With a higher QoS, macOS allocates it to a P core if one is available; if not, then it will be run on E cores, with that cluster running at high frequency. Thus, threads with a higher QoS can be run on either P or E cores, depending on their availability.

taskpolicy

There are times when you might wish to accelerate completion of threads normally run exclusively on E cores. For example, knowing that a particular backup might be large, you might elect to leave the Mac to get on with that as quickly as possible. There are two methods that appear intended to change the QoS of processes: the command tool taskpolicy, and its equivalent code function setpriority().

Experience with using those demonstrates that, while they can be used to demote threads to E cores, they can’t promote processes or threads already confined to E cores so that they can use both types. For instance, the command
taskpolicy -B -p 567
that should promote the process with PID 567 to run on both types of core, has no effect on processes or their threads that are run at low QoS. taskpolicy can be used to demote processes and their threads with higher QoS to use only E cores, though. Running the command
taskpolicy -b -p 567
does confine all threads to the E cluster, and can be reversed using the -B option for threads with higher QoS (but not those set to low QoS by the process).

That can be seen in this CPU History window from Activity Monitor. An app has run four threads, two at low QoS and two at high QoS. In the left side of each core trace they are run on their respective cores, as set by their QoS. The app’s process was then changed using taskpolicy -b and the threads run again, as seen in the right. The two threads with high QoS are then run together with the two with low QoS in the four E cores alone.

The best way to take advantage of this ability to demote high QoS threads to run them on E cores is in St. Clair Software’s excellent utility App Tamer.

Virtualisation

macOS virtual machines running on Apple silicon chips are automatically assigned a high QoS, and run preferentially on P cores. Thus, even when running threads at low QoS, those are run within threads on the host’s P cores. This remains the only known method of electively running low QoS threads on P cores.

Game Mode, CPU cores

In the Info.plist of an application, the developer should assign that app to one of the standard LSApplicationCategoryTypes. If that’s one of the named game types, macOS automatically gives that app access to Game Mode. Among its benefits are “highest priority access” to the CPU cores, in particular the E cores, whose use by background threads is reduced. Other benefits include highest priority access to the GPU, and doubled Bluetooth sampling rate to reduce latency for input controllers and audio output. Game Mode is automatically turned on when the app is put into full-screen mode, and turned off when full-screen mode is stopped, although the user also has manual control through the mode’s item in the menu bar.

In practice, while this is beneficial to many games, it has little if any use for modifying core type allocation in other circumstances. As the user can’t modify an app’s Info.plist without breaking its signature and notarization, this is only of use to developers.

Summary

• The QoS assigned by an app to its threads is used by macOS to determine which core type to allocate them to.
• Threads with a low (Background, 9) QoS are run exclusively on E cores. Those with higher QoS are run preferentially on P cores, and normally only on E cores when no P core is available.
• App Tamer and taskpolicy can be used to demote higher QoS threads to be run on E cores, but low QoS threads can’t be promoted to be run on P cores.
• macOS VMs run on P cores, so low QoS threads running in a VM will be run on P cores, and can be used to accelerate Background threads.
• Game Mode gives games priority access to CPU cores, particularly to E cores, but users can’t elect to run other apps in Game Mode, and there don’t appear to be benefits in doing so.
• If you feel an app would benefit from user control over CPU core type allocation through access to their QoS, suggest it to the app’s developer.

Explainer

Quality of Service (QoS) is a property of each thread in a process, and normally chosen from the macOS standard list:

• QoS 9 (binary 001001), named background and intended for threads performing maintenance, which don’t need to be run with any higher priority.
• QoS 17 (binary 010001), utility, for tasks the user doesn’t track actively.
• QoS 25 (binary 011001), userInitiated, for tasks that the user needs to complete to be able to use the app.
• QoS 33 (binary 100001), userInteractive, for user-interactive tasks, such as handling events and the app’s interface.

There’s also a ‘default’ value of QoS between 17 and 25, an unspecified value, and in some circumstances you might come across others.

Ovid’s sequel to the story of Pygmalion’s marriage to his former statue is a darker tale of incest, transformation, and obstetrics in the arboretum, resulting in myrrh and the unique birth of Adonis.

Pygmalion’s great granddaughter Myrrha was cursed by the Fates and blighted in love. Although she had many suitors, she fell in love with her father, King Cinyras. Ovid relates her long soliloquy in which she wrestles with her own mind over this. When her father asked her what to do about her suitors, she first stayed silent, then burst into tears, eventually confessing that she wanted a husband like her father.

That night she lay awake in bed, her mind in turmoil, until resolving that her only solution was suicide. She tied a noose around a beam in her bedroom, and was just about to hang herself from it when her old nurse came in. Eventually, Myrrha confessed to her shameful desire, and her nurse promised to arrange the matter for her.

When the festival of Ceres came, Cenchreis, Myrrha’s mother, was busy with her duties, allowing the nurse to arrange Myrrha’s liaison with her father. The nurse ensured that Cinyras had plenty to drink, and promised him a night making love to a girl as young as his daughter. Later that night, the nurse took Myrrha to her father, and put her to bed with him, making her pregnant. Myrrha and her father continued to sleep together night after night, Cinyras still oblivious of who his partner really was. Eventually, he brought in a lamp so that he could see her, and was shocked to discover his own daughter.

He drew his sword to kill her, but she fled and wandered in the desert until it was time for her child to be born. Myrrha then called on the gods to help her, but wanted to neither live nor die. She was transformed into a myrrh tree, providing the precious resin myrrh from the sap generated from her tears of grief.

Adonis, the child who had been growing within her, was then delivered by Lucina, goddess of childbirth, and laid on soft leaves by the Naiads to be anointed with his mother’s myrrh.

This classical fresco from the Golden House of Nero in Rome shows Lucina presenting Venus, who stands clutching the top of a myrrh tree, with the newborn Adonis.

Possibly one of Titian’s earliest works, although this is disputed and even Giorgione has been credited, this cassone panel of The Birth of Adonis probably dates from 1505-10. At the left, Myrrha and her father Cinyras lie together, although this would of course make certain his knowledge of her identity. In the centre, a baby is delivered from the woody womb of Myrrha as a tree, in multiplex narrative.

At about the same time, Bernardino Luini painted his fresco account of The Birth of Adonis (1509-10), which also adopts multiplex narrative to explain the origin of Myrrha’s pregnancy. In the foreground, the couple are shown together, and at the top left the miraculous birth has just taken place. In an alternative reading, the couple in the foreground could be Adonis as a young man, with the goddess Venus as his lover.

Over a century later, this wonderful panel was painted, showing The Birth of Adonis and Transformation of Myrrha. This was possibly after Luigi Garzi, although again its origin remains disputed. Reference to Myrrha’s dark past has been concealed, and she is here shown as a chimera between woman and tree, with the infant Adonis just delivered by a whole team of midwives and maids. The helper at the right wears a coronet with the crescent moon on it, signifying the goddess Diana. On the left side of the tree, one of the other helpers is holding up a tray with a small container of myrrh to anoint Adonis. In the foreground, a wingless putto is laying out a napkin for the infant.

One artist painted this story repeatedly: Marcantonio Franceschini, a Baroque painter in the Italian city of Bologna.

This version of Franceschini’s The Birth of Adonis probably dates from around 1685-90, and is now in Dresden. Myrrha is a distinctive cross between tree and woman, and a couple of satyrs are laughing in the bushes behind her. Two young women are rather pointedly looking in amazement at the origin of Myrrha’s baby. In the centre, Adonis is being given by Diana, with her crescent moon, to Venus, who stars in his later life, and is already admiring his beauty.

Franceschini’s later version from around 1692-1709 is now in Vienna, and arranges a similar composition into vertical format. Here Diana is handing Adonis over to another goddess, possibly Venus, who is preparing to assume the role of wet-nurse. Behind them, the two women looking in amazement appear to be less anatomically engaged, and Pan and a satyr are providing some celebratory music. The napkin-bearing putto is here a winged Cupid.

Apart from a slightly later painting by Boucher, which I have been unable to illustrate here, those seem to have been the last paintings of this disturbing story of the origins of myrrh and Adonis, until recently.

Contemporary artist Rafael Metz’s The Transformation of Myrrh and the Birth of Adonis (2006) shows only the final part of the story, as the infant is being cradled by another woman, under the chimeric tree of Myrrha with its ornate and decorative branches. Myrrh resin is already exuding from the bark.

I hope that you enjoyed Saturday’s Mac Riddles, episode 286. Here are my solutions to them.

1: Keeps an eye on exercise for checking 2, 3, memory and more.

2: Champion’s reward in disarray for the heart of your Mac, shown in 1.

3: Endless high status in hiding place for treasure can be shown in 1.

The common factor

I look forward to your putting alternative cases.

Following tests over two years ago, I recommended the use of sparse bundles (UDSB) rather than plain UDIF read-write (UDRW) disk images, because of their faster and more consistent performance. Since then, read-write disk images have adopted a sparse file format, making them more space-efficient. However, their write performance has remained substantially lower than sparse bundles, and the latter remain the preferred format.

More recent performance tests have confirmed this in Sequoia, as shown in the table below.

Most recently, tests of file compression showed relatively poor performance within a sparse bundle, with overall compression speed only 57% that of the SSD hosting the bundle despite apparently good write speeds. This article explores why, and whether that should alter choice of disk images.

Consistency in write speed

As previous articles note, inconsistent performance troubles disk images. Because of their complex bundle structure and storage across thousands of band files, it’s important to consider whether this poor performance is merely a reflection of that inconsistency.

The original Stibium write speed measurements, separated out from the collation shown in that recent article, show more dispersion about the regression line than other tests. As those are based on a limited number of file sizes, a total of 130 write speed measurements were performed using file sizes ranging from 4.4 MB to 3.0 GB, 50 of them being randomly chosen.

Those confirm that some individual write speeds are unexpectedly low, and dispersion isn’t as low as hoped for, but don’t make inconsistency a plausible explanation.

Band size

Unlike other types of disk image, data saved in sparse bundles is contained in many smaller files termed bands, and the maximum size of those band files can be set when a sparse bundle is created. By default, band size is set at 8.4 MB and there are only two ways to use a custom size, either when creating the sparse bundle using the command hdiutil create or in my free utility Spundle. Although those allow you to set a preferred band size, the size actually used may differ slightly from that.

Band size could have significant effects on the performance and stability of sparse bundles, as it determines how many band files are used to store data. Using a size that results in more than about 100,000 band files has in the past (with HFS+ at least) made sparse bundles prone to failure.

To assess the effect of different band sizes on compression rate, I therefore repeated exactly the same test file compression in sparse bundles with 12 band sizes ranging from 2.0 to 1020 MB, as measured rather than the value set.

In the graph above, time to complete the compression task is shown for each of the band sizes tested, and shows a minimum time (fastest compression) at a band size of 15.4 MB, of about 8.3 seconds, significantly lower than the 11.08 seconds at the default of 8.4 MB. Band sizes between 2.0-8.4 MB showed little differences, but increasing band size to 33.8 MB and greater resulted in much slower compression.

When expressed as compression rates, peak performance at a band size of 15.4 MB is even clearer, and approaches 1.9 GB/s, more than twice that of a read-write disk image, but still far below rates in excess of 2.6 GB/s found for the USB4 and internal SSDs. With band sizes above 33.8 MB, compression rates fall below those of a read-write disk image.

Another way of looking at optimum band size is to convert that into the number of band files required. Fastest rates were observed here in sparse bundles that would have about 6,000-7,000 bands in total when the sparse bundle is full, and in this case with 2,000-2,300 band files in use. Performance fell when the maximum number of band files fell below 3,000, or those in use fell below 1,000.

Streaming

Compression tests impose different demands on storage from conventional read or write benchmarks because file data to be compressed is streamed by reading data from storage, and writing compressed data out to the same storage device. Although source and destination are separate files, allowing simultaneous reading and writing, if those files are stored in common band files, it’s likely that access has to be limited and can’t be simultaneous.

As observed here, that’s likely to result in performance substantially below that expected from single-mode transfer tests. Unfortunately, it’s also extremely difficult to measure attempts to simultaneously read and write from different files in the same storage medium.

Conclusions

• Sparse bundles (UDSB) remain generally faster in use than read-write (UDRW) disk images.
• Sparse bundle performance is sensitive to band size.
• Default 8.4 MB bands aren’t fastest in all circumstances.
• When sparse bundle performance is critical, it may be worth optimising band file size instead of using the default.
• Tasks that stream data from and back to the same storage are likely to run more slowly in a sparse bundle than on its host storage.

Previous articles

Dismal write performance of Disk Images
Which disk image format?
Disk Images: Performance

A century ago today, 15 December, the French artist Henri Jules Jean Geoffroy died in Paris. Also known by his pen name of Géo, he is one of the great painters of children and childhood in the European canon.

Geoffroy was born the son of a tailor in Marennes, on the west coast of France, half way up the Bay of Biscay. He went to study in Paris, probably at the École des Beaux Arts in about 1871, where he’s claimed to have been a pupil of Léon Bonnat and others, although Bonnat didn’t become a professor there until 1882.

He first exhibited at the Salon in 1874, when he was just 21. From 1876, he undertook commissions to illustrate books about childhood and youth for the publisher Pierre-Jules Hetzel (1814-86), who also published the work of Gustave Doré, and discovered the author Jules Verne. Despite this promising start, Geoffroy doesn’t seem to have achieved much artistic recognition until the mid 1880s, by which time he signed himself simply as Géo.

Around 1879-1882, Geoffroy painted this work showing a well-known scene from Victor Hugo’s Les Miserables, of Jean Valjean and Cosette. This shows the hero Valjean when he arrives in Montfermeil on Christmas Eve and discovers young Cosette fetching a pail of water for her abusive guardians the Thénardiers, early in the novel.

He followed that with Whoever Breaks the Glass Pays for It in 1881. This shows a group of three young boys who have apparently broken a glass from a street café. The boy at the right is pointing down at the fragments of glass on the ground, and looking daggers at the other two. He is being admonished by the street vendor whose glass has been broken, and has been told that he has to pay for the damage. Geoffroy gives subtle insight into the social background in the children’s clothing: the apparently uninvolved boy at the left wears clean and fancy boots, while the one at the right who is assumed to be the miscreant wears worn and dirty clothing and footwear.

By 1882, Geoffroy had entered the schools where he was to be most successful and prolific; he apparently lodged above a school, with a couple of teachers. Snack Time shows the pupils outside their primary school during a break, armed with their lunchboxes and baskets. Again he tells their stories using subtle hints including their clothes. A well-dressed girl in white is being harassed by a smaller boy into surrendering some of her food. He wears rougher clothes but seems in control of the situation, as others watch on and laugh.

In 1885, he was appointed a knight in the Legion of Honour.

Geoffroy’s painted insights into the world of childhood extend to illness and the hospital. In his dazzlingly modern and clinical Visiting Day at the Hospital from 1889, the boy’s father clearly could never have afforded state-of-the-art care for his sick son. Although probably understood by the contemporary viewer, the painting doesn’t reveal to modern eyes that the boy is most probably dying of tuberculosis, an all too common problem at the time.

In Primary School Class from 1889, Geoffroy shows one of the new lay teachers, introduced by the Third Republic, working diligently in the classroom with her pupils. This was clearly deemed sufficiently positive to the State as to be purchased by the French National Ministry of Education, where it still hangs.

Less welcomed by the State was The Night Hostel or The Soup Kitchen from 1891, showing homeless women and children being fed and sheltered in what appears to be almost a prison.

Returning to school scenes in 1895, Geoffroy shows a Drawing Lesson in a class of older boys, who are following the classical tradition of drawing casts and appear remarkably diligent and well-behaved.

Geoffroy’s The Nursery from 1899 is one of very few paintings showing modern approaches to the early rearing of children under the Third Republic. Hospitals developed a rigorous almost military approach to nurseries and feeding that endured well into the twentieth century, and separated mothers from their infants for much of the time.

In 1900, at the Exposition Universelle in Paris, Geoffroy was awarded a gold medal, forming the peak of his career.

In Geoffroy’s In School from about 1900, another lay teacher in a modern Republican infants class is caring for the French men and women of the future.

Bastille Day, from the same year, shows a group of children celebrating the national day of France on 14 July. For young boys in the years before the First World War, this was becoming increasingly militaristic rather than just patriotic.

I have been unable to locate an image of Geoffroy’s painting from which Charles Baude made this print of Prize-Giving at an Infants School in 1904, but it is a fine example of the artist’s depictions of groups of young children and their social interactions.

This undated painting of It’s Hard to Share shows another of the tribulations of childhood. These young boys have just emerged from a sweet shop, and the child in the centre is reluctant to share the paper cone of sweets he has just bought. His face says it all, as he looks with great suspicion at his less fortunate friend, and a dog also looks up expectantly.

I have been unable to find any of Geoffroy’s later paintings, and he died in Paris in 1924, at the age of 71.

Over the fifty years since I started using computers, one of the greatest changes has been who does the waiting. In my early days, it was me, in some cases waiting overnight for batches to be processed on a mainframe computer. By the mid 1990s I had to wait a couple of days for some of my optimisation runs to complete on the Mac in my office. Since then, as Macs have got progressively faster, they have come to do the waiting for me. Whether I’m editing an image or writing an article, my Mac keeps pace with almost everything I do.

One notable if infrequent exception is when there’s a macOS update. On a newer Apple silicon model, installation itself is far quicker than when Apple changed to using the SSV in Big Sur, but there’s always that wait for the downloaded update to be “prepared” in the background. Much of that is thought to be decompression, which minimises the size of downloads by putting the burden on the Mac to expand and organise what needs to be installed.

Data compression is widely used in modern operating systems. Take a look in Activity Monitor’s Memory view, and at the bottom right you’ll see how much compressed memory is in use, here currently over 1 GB. It’s used to save space in macOS, where many system files are stored in compressed formats. Compression is also an integral part of many media formats, whether still or moving images, or audio. Unless they’re compressed, we’d only be able to enjoy a small fraction of the media we now consume so voraciously.

It’s understandable that compression is thus one of the best-studied tasks in computing. Over decades of intensive research and practical experience, we have learned that the most powerful methods of compressing data can also take the most processing time. The effectiveness of compression is generally expressed in terms of compression ratio, the ratio of original file size to that of the compressed file. Thus all effective compression methods should result in a compression ratio of more than 1. You’ll also come across percentage space saving, the reduction in size compared to the original. If a compression method shrinks a 10 GB file to 5 GB, then its compression ratio is 10/5 = 2, and its space saving is (1 – 5/10) x 100 = 50%.

One of the most efficient compression techniques has been that in nanozip 0.09a, for instance, which can achieve a compression ratio of 5.3, or a space saving of 81%, on English text taken from Wikipedia. This illustrates the trade-offs made in such efficient techniques, as to achieve that it takes almost 128 seconds to compress 100 MB, a rate of 0.783 MB/s. That makes it of little everyday use and unsuitable for macOS updates, where it also couldn’t achieve the same high compression ratio because the data are binary rather than English text.

Optimising compression isn’t as simple as it might appear. There’s an inverse relationship between the time spent compressing data and the amount of compressed data to be written, as there is with many similar tasks. The more sophisticated the compression and the higher the compression ratio, the less data there is to be written out, although there’s still the same amount of data to be read. Using the example of a compression ratio of 2, 10 GB of input data has to be read and only 5 GB written out, so unless write speed is less than half read speed, reading the input data is likely to be more rate-limiting.

Compression is also representative of many other types of everyday tasks, as it consists of three sub-tasks:

1. read data from disk
2. process it (encode, decode, transcode)
3. write the transformed data to disk

Unless you use small file sizes, this is usually performed on data streamed from storage and back to storage, rather than on single chunks of data in memory.

To understand what limits performance of any of those everyday tasks, we need to understand how each of its sub-tasks is limited, and how those limitations interact. In some cases, such as preparation of macOS updates, time taken appears to be determined by the processing required in the second step. In the past, Apple has run all that in a single thread to minimise impact on concurrent use of other apps in the foreground. In other tasks, such as encrypting files, stage 2 processing should be fastest, making it most likely that disk access is limiting.

Although we can’t apply conclusions drawn from studying any specific compression method, we can use it as a model to develop tools that we can then apply to other tasks. Over the last week, I’ve published two articles here discussing how to do that.

In the first I asked how we can investigate whether more threads will run a task faster. We know that for my compression task they do, but that may not be true for the tasks you’re most interested in accelerating. In rare cases, an app may provide a control to set how many threads to use, and it’s easy to use that to investigate. It’s more likely that your app has no such control, but one way around that is to run it in a virtual machine, where you can pick the number of virtual cores to host that VM.

Timing the performance of your app with test files of known size should give a performance rate, and that can help identify which of those sub-tasks is probably limiting overall performance. If your app transcodes video, for example, and you time how long it takes to complete all three sub-tasks on a 10 GB video clip, you can work out its transcoding rate in GB/s. If that test clip takes 20 seconds to read that test file, transcode it, and write out the converted video, then its overall transcoding rate is 0.5 GB/s.

The next article considers how you might work out whether running that task on high-speed storage would improve that overall performance. Although it looks unlikely that a transcoding rate of 0.5 MB/s would be altered by running it on a Thunderbolt 3 disk with its 2.3 GB/s write speed, it’s worth comparing performance on the faster internal SSD to check that, and decide whether a faster USB4 SSD might be better.

By the time that you’ve worked through those tests, you should have better insight into which of those three sub-tasks is limiting performance, how you might be able to improve them, and compare current performance in the overall transcoding rate against attempts at improvement. As I wrote last week, the only way to do that is with objective measurements such as that transcoding rate.

Next week I’ll continue this series by considering how you can control the type of CPU core threads run on, and some related issues about sparse bundles and the performance of Time Machine backup storage.

Two centuries ago today, 14 December, the major French painter Pierre Puvis de Chavannes was born in Lyon. In this second and concluding article celebrating his career and art, I continue from the years following the Franco-Prussian War, when his work achieved broad appeal despite the bitter divisions in French society. Their unreal and classical motifs painted in a plain style using pale colours must have been refreshingly different from social realism, the Academy, and the increasingly sketchy landscapes of the Impressionists. Puvis responded by painting increasingly symbolic themes in the same style.

Death and the Maiden from 1872 is most probably based on Schubert’s song of the same title, expressing the inevitability of death, almost in terms of vanitas, which had last been popular during the Dutch Golden Age. This linked with the recent war, when so many young French and Prussian people had died, and with contemporary scourges such as tuberculosis, which killed many young adults. The maidens are seen dancing together, and picking wild flowers, as the personification of death is apparently asleep on the grass at the lower left, his black cloak wrapped around him and his hand resting on the shaft of his scythe.

Completed for and exhibited at the Salon of 1879, Young Women at the Seaside must be one of the palest and plainest paintings of any visit to the beach. Only one of the three young women faces the viewer, and she looks as if she’s about to die of ennui. Even the sea looks cold and distant.

Two years later, in 1881, Puvis exhibited The Poor Fisherman (1881), which proved to be one of his most successful works. Significantly more colourful, he provides more detail, although keeping well away from anything that might be mistaken for social realism or the increasingly popular Naturalism. A thin if not quite emaciated fisherman stands, Christ-like, in his boat waiting for his catch to fill his net. Behind him on the marshy land is his wife picking flowers, and their infant, another possible reference to Jesus Christ.

Puvis painted at least four versions of this work, it was reproduced as a lithograph, and numerous contemporaries copied and admired it, declaring its importance in the development of painting at the time. It’s thus one of the formative works leading to the Symbolist movement, whose manifesto was published five years later.

In 1882, Puvis painted the much paler Pleasant Land, which returns to the south coast of France and a small group of young women and their children who are engaged in dolce far niente just above the beach.

For the Salon of 1883, Puvis intensified the unreality with his nocturne The Dream. In a similarly placid and contemplative Mediterranean coastal setting, a traveller (vagrant), their meagre possessions tied up in a cloth, is asleep under a crescent moon. Three angelic but wingless figures from a dream are shown in mid-air, two scattering stars and one bearing a laurel wreath.

Puvis had painted a succession of murals in France from the 1860s onwards. During the 1880s, these turned increasingly to the recurrent motif of classical figures in a sacred grove.

This panoramic easel painting of The Sacred Grove, Beloved of the Arts and the Muses, made in the period 1884-89, is a good example of this series. Puvis alludes to the Muses, but doesn’t identify them with their customary attributes. Instead, two women (wingless again) are flying, one apparently playing the lyre. The figures below are engaged in contemplation, discussion, and the central group are listening to a recital of poetry or song. Most of them wear golden laurel wreaths in their hair, and all are dressed in classical robes.

Charity (1887) is a personification of one of the seven Christian virtues, again set in timeless classical terms. She is the mother of twins, one of whom she holds by her breast. She is clasping the back of the neck of a dark wolf, lying beside her, adding a more unusual touch. This had become a popular motif, and only nine years previously had been painted by William-Adolphe Bouguereau in contrasting Academic style.

Of his surviving murals, I think The Sacred Wood is perhaps the most impressive. Completed in 1889, it graces Le Grand Amphithéâtre of La Sorbonne in Paris, and is his ultimate expression of this theme. It includes many classical and artistic references: near the centre, bent over the surface of a pond, is Narcissus, and towards the right, dressed in red, what looks like Dante.

In 1890, Puvis was co-founder and first president of the Société Nationale des Beaux-Arts, which became the dominant Salon in Paris.

Puvis continued his low-chroma paintings of coastal scenes with The Shepherd’s Song in 1891. Oddly, the shepherd referred to in the title is the smallest of its figures, perched part-way up an ill-defined rocky slope at the left, above two black goats, as three women are fetching water in the foreground.

During the early 1890s, Puvis developed the theme of the sacred grove and relocated it to a hillside above the city of Rouen, in his Inter artes et naturam (meaning Between Art and Nature), from about 1890-95. His viewpoint is Bonsecours, to the south-east of the city, looking north-west over its bridges and distinctive skyline. Clothing worn suggests a curious conflation of periods, from the classical at the left edge, to the contemporary at the mid-right.

The last of these paintings is The Poet from 1896, which returns to the Mediterranean coast, where a poet, who has just dropped his lyre behind him, is swooning, as a winged angel comforts and supports him. At the upper right is a white dove representing the Holy Spirit. Perhaps this was his prescience of death.

Pierre Puvis de Chavannes died in Paris, where he had worked most of his life, on 24 October 1898, at the age of 73. Only three months before, he had finally married his partner of more than forty years, a Romanian princess who died just a month after their wedding.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Keeps an eye on exercise for checking 2, 3, memory and more.

2: Champion’s reward in disarray for the heart of your Mac, shown in 1.

3: Endless high status in hiding place for treasure can be shown in 1.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

In the days of Classic Macs, most of our concerns centred on memory rather than CPU, disk or network performance. Tools for managing memory flourished, and I don’t recall any utility provided in Mac OS that looked more broadly. That changed when Mac OS X arrived, and we started taking an interest in Process Viewer and CPU Monitor.

CPU Monitor, seen here in 2001 with its two floating chart views, was a first step in development. I suspect this was taken on my QuickSilver Power Mac G4 with its dual processors, hence the pair of CPU charts.

Process Viewer is a more obvious ancestor of the modern Activity Monitor, with its list of processes in a column view. Note the surprisingly few system processes running at the time: only 34, compared with today’s list of several hundred.

Activity Monitor integrated those features into its new app in Mac OS X 10.3 Panther in 2003, and is shown here in 10.4 Tiger from a couple of years later, where it’s surprisingly similar to the current app. There are still only 72 processes running, though, and most have less than 5 threads.

Here’s Activity Monitor with its CPU History window on an 8-core Mac Pro, running Mac OS X 10.7 Lion in 2011. The number of processes is still only growing slowly, and had reached 89.

Xcode’s Instruments added an Activity Monitor template for developers wanting to monitor further details as they tested and debugged their code. At this stage it was limited to presenting the same fundamental measurements as were available in Activity Monitor, but these have since flourished into much greater depth.

Two years later, in 2013 for OS X 10.9 Mavericks, Activity Monitor underwent revision to add a new tab for Energy. Unlike other panes, the ‘Energy Impact’ is given in arbitrary units rather than calculating Joules from power use over time. It was at about this time that the app also added a Cache pane analysing the performance of the Content Caching service, when enabled on the Mac.

Until 2020, Activity Monitor had dealt with CPUs with uniform cores. Above are the eight physical and eight Hyper-threaded cores in an 8-core Intel Xeon W in an iMac Pro from 2017, running a heavy load of over 700% CPU. With the first Apple silicon Macs, it had to display CPU use for two different types of core. Note how, by 2020, the total number of processes has shot up to 458.

This is an example from one of the first base M1 Macs, with 4 Efficiency and 4 Performance cores displayed neatly in its CPU History window. Although Activity Monitor doesn’t take core frequency into account when measuring % CPU, and can’t display cluster frequencies, it remains one of the essential tools for everyone, whichever age and architecture their Mac.

Two centuries ago tomorrow the major French painter Pierre Puvis de Chavannes was born in Lyon. In this and tomorrow’s concluding article I briefly celebrate his career and work.

Puvis had never intended to be an artist, but serious illness cut short his studies, and after his convalescence he travelled to Italy. He there became inspired to paint, studying briefly under Eugène Delacroix before he closed his studio. He was then a pupil under Henri Scheffer and Thomas Couture, but proved something of a loner and didn’t follow contemporary Academic tradition. Although his first paintings were accepted for the Salon in 1850, recognition didn’t come until much later.

Puvis painted two completely different versions of The beheading of John the Baptist. This is the earlier, from 1856, alternatively known as The Daughter of Herodias Gives the Signal for the Ordeal of Saint John the Baptist, which in itself raises questions. Salome dominates the painting, her right hand holding the empty platter high above her head as she is about to drop it to signal John’s execution. John the Baptist is still alive at this stage, seen in the murky distance at the left. Another figure, perhaps Herodias, is hiding in Salome’s robe, behind her.

His later painting, from about 1869 and in the National Gallery in London with a smaller version in Birmingham, is more in accord with the biblical account of this story.

The Wine Press, from about 1865, is more typical of his mature paintings, showing a classical figurative motif executed simply using low chroma throughout. In this case, a bearded young man wearing a wreath as a loincloth stands awkwardly on a wooden step-ladder, tipping freshly harvested grapes into the large wooden press. Three young women, dressed loosely in classical robes, are delivering him the grapes from the vineyard, as a pair of longhorned cattle look on.

During the 1860s, Puvis reacted to the popular trend towards realism by painting increasingly unreal works, such as Fantasy from 1866. Two naked people of indeterminate gender are in an idyllic wooded landscape near the foot of sheer cliffs. One sits plucking flowers to form a wreath, the other uses a length of ivy to school a winged white horse which could be Pegasus or a hippogriff. Puvis’ application of paint is so thin that the wings of the horse are semi-transparent, and his colours are muted in the extreme. In almost every respect, this was the antithesis of social realism, pre-Impressionist landscapes and Academic painting of the time.

Puvis increasingly turned to allegory and personifications, as in this painting of Vigilance, completed in 1866 and accepted for the Salon of that year. Traditional attributes associated with this personification are the oil lamp she holds aloft, a book and a rod, which are omitted.

The following year Puvis painted a pair of allegories, Peace (above) and War (below), using stronger colours to make it easier to read their greater detail. Both are set in classical times in an idyllic landscape. Peace is a group dolce far niente which would later have passed for Aestheticism: men, women and children engaged in nothing more strenuous than milking a goat.

In War, three horsemen are blowing a fanfare on their war trumpets, haystacks in the surrounding fields are alight and pouring black smoke into the sky, and the people are suffering, even though signs of destruction are slight and none is wounded. The timing of these paintings wasn’t coincidence: France was in the process of sliding inexorably towards its war with Prussia, and the Second Empire of Napoleon III was about to self-destruct.

Shortly before the Franco-Prussian War, he painted this unusual and relatively colourful maritime scene of Marseilles, Gateway to the Orient (c 1868). Set aboard a fanciful sailing ship, it shows the mixed ethnicity of those who crewed and travelled in the vessels trading through the port of Marseille, on the Mediterranean coast. The city itself is in the distance, making its title the more odd. I suspect this was a study for one of the murals he made for the Musée des Beaux-Arts in Marseilles in the 1860s.

Puvis was deeply affected by the Franco-Prussian War, and the Paris Commune that followed in 1871.

The role of balloons during the siege of Paris was inspiration for The Balloon of 1870, which became popular as a lithograph made by Émile Vernier. The following year, Puvis painted a pendant The Pigeon (below), showing another means of communication used during the siege.

Here a woman seen almost in silhouette waves at one of the balloons bearing news, as it flies near Mount Valérien. In her right hand she holds a musket, symbolic of the arming of the people of Paris at the time. The same woman appears in mourning in The Pigeon, collecting a carrier pigeon that had fought its way through the predatory hawks flown by the Prussians.

The two paintings meant a great deal to Puvis, who reluctantly gave them to the government a few years later, to be prizes in a lottery organised to provide aid to the survivors of the great fire of Chicago in 1871. They didn’t return to Paris until 1987, and are now both in the Musée d’Orsay.

Puvis’ Hope from 1872 develops this post-war theme further, and was exhibited at the Salon that year, the first to follow the war. A young woman sits amid a landscape that has been destroyed by fighting. The bleached rubble of a farmhouse is seen in the right distance, and there are two improvised graveyards with clusters of crosses. She holds a sprig of oak as a symbol of the recovery of the nation.

His three paintings provoked reflection rather than taking sides, and became popular across the range of public opinion. They proved a turning point in his career, as I’ll show tomorrow.

If, like me, you pay close attention to firmware updates released with macOS, you may have noticed something highly unusual if not unique this week, in the firmware updates that came with macOS Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2: those could mark the end of an era.

All new Macs since Apple transitioned to using Intel processors have one of three classes of firmware:

• Intel Macs without a T2 chip only have EFI firmware, whose version reads something like 529.140.2.0.0. These are model-specific.
• Intel Macs with a T2 chip have firmware for both their Intel systems in EFI, and iBridge for the T2, giving them a double firmware version like 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). All models with a T2 chip can run the same EFI and iBridge versions.
• Apple silicon Macs have iBoot, with a version like 11881.61.3, which is common across all models.

This complexity was the reason for my first developing EFIcienC, predecessor to SilentKnight, compiling and maintaining databases of firmware versions, and trying to help those whose Macs stubbornly refused to update their EFI firmware when they should have done. This site still has long lists of the latest firmware versions for Macs running Catalina, for example.

As the number of supported Intel Macs without a T2 chip has steadily fallen, what used to be a long and complex list has shrunk to just seven models. With the release of macOS Sequoia 15.0, Sonoma 14.7 and Ventura 13.7, Apple stopped updating the EFI firmware for Intel Macs without T2 chips, which are now frozen as they were last June and July.

When Apple released Sequoia 15.2, Sonoma 14.7.2 and Ventura 13.7.2 this week, it appears to have ceased updating the EFI firmware in Intel Macs with T2 chips.

T2 models were updated to EFI 2069.0.0.0.0 and iBridge 22.16.10353.0.0,0 when Sequoia 15.0 was released on 16 September 2024. No firmware updates came in the rapid update to 15.0.1, but in 15.1 those models were updated to EFI 2069.40.2.0.0 and iBridge 22.16.11072.0.0,0.

Sequoia 15.1.1 also didn’t bring any change in firmware, and 15.2 updates T2 models to EFI 2069.40.2.0.0 and iBridge 22.16.12093.0.0,0: while the T2’s firmware has been updated, no change has been made in the EFI version. As far as I’m aware that’s the first time that has happened since the initial releases of T2 firmware at the end of 2017 and early 2018. The first record I have of their version numbers is of EFI 1037.147.1.0.0 and iBridge 17.16.16065.0.0,0, since when they have come a very long way.

While I’m sure that Apple could still update EFI firmware if necessary, I think we have seen the last planned updates, with only iBridge for the T2 and iBoot for Apple silicon Macs to continue to advance with future releases of macOS. As the T2 is also Apple silicon, that means an end to the last firmware for Intel processors, after more than 18 years. The end of an era indeed, and time to pour one out for EFI firmware in Macs.

I wouldn’t like to hazard a guess at how much longer Apple will continue to support iBridge firmware for T2 chips. Firmware updates aren’t a required part of macOS updates, and most Macs cease to enjoy them well before they’re updated to their last macOS.

At the end of each year I trawl through images of paintings that are thought to have been created a century ago. Together they show how rich and varied art was at a time when most histories are devoted to accounts of the rise of modernism. Today’s collection of work from 1924 consists of portraits, self-portraits and other figurative paintings.

Although the great majority of paintings seen in galleries and collections are made in oils, or watercolours, my first two works were both created in pastels by specialists in that medium.

Firmin Baes’s double portrait of Two Brothers was painted using pastels, in the studio against a backdrop perhaps showing their home in the countryside.

Ants Laikmaa was another accomplished pastellist who painted many fine portraits. Among them is this posthumous Portrait of Fr. R. Kreutzwald, also known as In the Distance I See Home Thriving. Friedrich Reinhold Kreutzwald (1803-1882) is the father of Estonian national literature, and in addition to being a distinguished physician, he is the author of the national epic Kalevipoeg which is closely related to the Finnish epic, the Kalevala.

Léon Bakst is best known for his designs for Sergei Diaghilev and the Ballets Russes, but in the years following the 1917 Revolution he painted portraits. He completed this Portrait of Rachel Strong, future Countess Henri de Buazhelen against a background that could have been one of his stage sets.

Lovis Corinth was nearing the end of his life when he painted his wife in Carmencita, Portrait of Charlotte Berend-Corinth in Spanish Dress. She was an artist in her own right, and had continued painting in the early twentieth century, joining the Berlin Secession in 1912. She also painted actively when at their chalet. In 1933, after her husband’s death, she emigrated to the USA, where she produced the first catalogue raisonné of his paintings.

Corinth painted other members of his family at this time. His Wilhelmine in a Yellow Hat shows their shy daughter starting to develop her mother’s vivacity.

His Large Self-portrait in Front of Walchensee illustrates his race against time before he died the following year.

Five to Twelve was one of Christian Krohg’s last paintings, showing the artist with a long white beard, and almost bald, asleep in a chair underneath a pendulum clock. The face of the clock is completely blank, but the title tells us the time: it’s ten minutes to midnight, very late in his life. The following year Krohg retired as the director of the State Academy of Art, and died in Oslo a few months later.

For Emily Carr 1924 was a crucial year, in which she met with Seattle artists, most importantly Mark Tobey, who helped rebuild her confidence in her art. Her Self-portrait shows her still suffering from her earlier rejection, as she faces away from the viewer, and is working on a painting that is unrecognisably vague and formless.

Meanwhile, Pierre Bonnard’s life in the Midi was coming to something of a crisis.

Several of the artists who had moved to the French Mediterranean coast around the turn of the century were keen yachtsmen. Here Bonnard shows Paul Signac on board his yacht, in Signac and his Friends Sailing.

Bonnard’s private life hadn’t found the same fair winds, though. In Before Dinner, there are two places laid at the table, and two women behind. One at the left has her back towards the other, who stands by the table as if waiting for something to happen. A dog is just emerging from behind the chair at the left, and looks up the standing woman. The following year Bonnard finally married his longstanding partner Marthe in a quiet civil ceremony in Paris, in August. None of their friends attended that wedding, and within a month his former lover Renée Monchaty shot herself in the chest, as she lay in a bath of white roses.

Late in his career, the radical artist Paul Sérusier drew more heavily again on early modern painting, including that of the late Middle Ages in paintings such as Tapestry (Five Weavers). So much for modernism.

The most common economy that many make when specifying their next Mac is to opt for just 512 GB internal storage, and save the $/€/£600 or so it would cost to increase that to 2 TB. After all, if you can buy a 2 TB Thunderbolt 5 SSD for around two-thirds of the price, why pay more? And who needs the blistering speed of that expensive internal storage when your apps work perfectly well with a far cheaper SSD? This article considers whether that choice matters in terms of performance.

To look at this, I’m going to use the same compression task that I used in this previous article, my app Cormorant relying on the AppleArchive framework in macOS to do all the heavy lifting. As results are going to differ considerably when using other apps and other tasks, I’d like to make it clear that this can’t reach general conclusions that apply to every task and every app: your mileage will vary. My purpose here is to show how you can work out whether using a slower disk will affect your app’s performance.

Methods

In that previous article, I concluded that compression speed was unlikely to be determined by disk performance, as even with all 10 P cores running compression threads, that rate only reached 2.28 GB/s, around the same as write speed to a good Thunderbolt 3 SSD. For today’s tests, I therefore set Cormorant to use the default number of threads (all 14 on my M4 Pro) so it would run as fast as the CPU cores would allow when compressing my standard 15.517 GB IPSW test file.

I’m fortunate to have a range of SSDs to test, and here use the 2 TB internal SSD of my Mac mini M4 Pro, an external USB4 enclosure (OWC Express 1M2) with a 2 TB Samsung 990 Pro SSD, and an external 2 TB Thunderbolt 3 SSD (OWC Envoy Pro SX). As few are likely to have access to such a range, I included two disk images stored on the internal SSD, a 100 GB sparse bundle, and a 50 GB read-write disk image, to see if they could be used to model external storage. All tests used unencrypted APFS file systems.

The first step with each was to measure its write speed using Stibium. Unlike more popular benchmarking apps for the Mac, Stibium measures the speed across a wide range of file sizes, from 2 MB to 2 GB, providing more insight into performance. After those measurements, those test files were removed, the large test file copied to the volume, and compressed by Cormorant at high QoS with the default number of threads.

Disk write speeds

Results in each test followed a familiar pattern, with rapidly increasing write speeds to a peak at a file size of about 200 MB, then a steady rate or slow decline up to the 2 GB tested. The read-write disk image was a bit more erratic, though, with high write speeds at 800 and 1000 MB.

At 2 GB file size, write speeds were:

• 7.69 GB/s for the internal SSD
• 7.35 GB/s for the sparse bundle
• 3.61 GB/s for the USB4 SSD
• 2.26 GB/s for the Thunderbolt 3 SSD
• 1.35 GB/s for the disk image.

Those are in accord with my many previous measurements of write speeds for those types of storage.

Compression rates

Times to compress the 15.517 GB test file ranked differently:

• 5.57 s for the internal SSD
• 5.84 s for the USB4 SSD
• 9.67 s for the sparse bundle
• 10.49 s for the Thunderbolt 3 SSD
• 16.87 s for the disk image.

When converted to compression rates, sparse bundle results are even more obviously an outlier, as shown in the chart below.

There’s a roughly linear relationship between measured write speed and compression rate in the disk image, Thunderbolt 3 SSD, and USB4 SSD, and little difference between the latter and the internal SSD. These suggest that disk write speed becomes the rate-limiting factor for compression when write speed falls below about 3 GB/s, but above that faster disks make little difference to compression rate.

Poor performance of the sparse bundle was a surprise, given how close its write speeds are to those of the host internal SSD. This is probably the result of compression writing a single very large file across its 14 threads; as the sparse bundle stores file data on a large number of band files, their overhead appears to have got the better of it. I will return to look at this in more detail in the near future, as sparse bundles have become popular largely because of their perceived superior performance.

The difference in compression rates between USB4 and Thunderbolt 3 SSDs is also surprisingly large. Of course, a Mac with fewer cores to run compression threads might not show any significant difference: a base M3 chip with 4 P and 4 E cores is unlikely to achieve a compression rate much in excess of 1.5 GB/s on its internal SSD because of its limited cores, so the restricted write speed of a Thunderbolt 3 SSD may not there become the rate-limiting factor.

Conclusions

• The rate-limiting step in task performance will change according to multiple factors, including the effective use of multiple threads on multiple cores, and disk performance.
• There’s no simple model you can apply to assess the effects of disk performance, and tests using disk images can be misleading.
• You can’t predict whether a task will be disk-bound from disk benchmark performance.
• Even expensive high-performance external SSDs can result in noticeably poor task performance. Maybe that money would be better spent on a larger internal SSD after all.

The macOS 15.2 update includes the second phase of AI support for Apple silicon Macs, introducing the Image Playground app, and integrated ChatGPT support in both Siri and Writing Tools. AI now extends support to several of the non-US variants of English, including English (UK), although non-English languages won’t gain support until next year.

Apple’s release notes are a real joy to read and contain more detailed information at last, including the following:

• Photos enhancements,
• Safari supports background images for its Start Page, tries to use HTTPS on all sites, and more,
• Sharing item locations in Find My,
• Sudoku for News+,
• Presenter preview for AirPlay,
• Pre-market quotes in Stocks.

Among the more significant bugs fixed is that Apple silicon virtualisation on M4 Macs can now open all VMs, including macOS guests before 13.4. For those running Ruby with YJIT enabled, this update should fix kernel panics with M4 chips. Further fixes are detailed in the developer release notes, and enterprise release notes are here.

Security release notes are available here, and list 42 entries including 4 in the kernel, none of which Apple reports may already have been exploited.

iBoot firmware on Apple silicon Macs is updated to version 11881.61.3, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). The macOS build number is 24C101, with kernel version 24.2.0.

Version changes in bundled apps include:

• Books, version 7.2
• Freeform, version 3.2
• iPhone Mirroring, version 1.2
• Music, version 1.5.2
• News, version 10.2
• Passwords, version 1.2
• Safari, version 18.2 (20620.1.16.11.8)
• Screen Sharing, version 5.2
• Stocks, version 7.1
• TV, version 1..5.2
• Tips, version 15.2
• VoiceMemos, version 3.1.

Inevitably, there are many build increments in components related to Apple Intelligence, and a great many across private frameworks. Other significant changes to /System/Library include:

• Screen Time, build increment
• Siri, version increment
• VoiceOver, build increment
• Kernel extensions including AGX… kexts, AOP Audio kexts, AppleEmbeddedAudio, AppleUSBAudio, and several virtualisation kexts
• One new kernel extension, AppleDisplayManager
• APFS to version 2317.61.2
• Most of the Core frameworks have build increments
• FileProvider framework, build increment
• Virtualisation framework, build increment
• PrivateCloudCompute framework, new version
• Spotlight frameworks, build increments
• New private frameworks include Anvil, AppSystemSettings (and its UI relative), AskToDaemon, many Generative… frameworks involved with AI, OSEligibility, TrustKit, WalletBlastDoorSupport
• Several qlgenerators have build increments.

After that lot, the next scheduled update to macOS Sequoia is in the New Year.

As eagerly anticipated, Apple has released the update to macOS 15.2 Sequoia, together with security updates to bring Sonoma to version 14.7.2, and Ventura to 13.7.2. There should also be Safari updates to accompany the latter two.

For Intel Macs, the Sequoia update is 2.72 GB in size, and for Apple silicon models it’s 3.45 GB.

Security release notes for Sequoia list 42 vulnerabilities fixed in the 15.2 update, including four in the kernel, although none are noted as being currently exploited. Release notes for Sonoma list 25, and those for Ventura list just 22.

iBoot is updated to version 11881.61.3 on Apple silicon Macs, and Intel Macs with T2 chips have their firmware updated to 2069.40.2.0.0, iBridge 22.16.12093.0.0,0. Sequoia 15.2 brings Safari version 18.2 (20620.1.16.11.8).

Later tonight I hope to post a summary of changes in 15.2, in a separate article as usual.

[Updated 1938 GMT 11 December 2024.]

During the nineteenth century, paintings depicting ‘real’ life of ordinary people became increasingly popular, first in what has become known as social realism, pioneered by Jean-François Millet, then Naturalism, championed by Jules Bastien-Lepage until his untimely death in 1884. Among other themes, these put the case for the rural poor, and the desperate poverty that those living in the country had to endure.

Look carefully at many of their paintings, though, and the underlying stories aren’t as simple. One of the most evident problems is that many of those campaigning paintings used models who had been carefully posed. Look at their hands, feet and hair and you’ll often see someone who appears remarkably clean and kempt with no evidence of prolonged and arduous manual labour, even clothes that lack the dirt and mud so typical of those who work and walk on unpaved tracks and ploughed fields.

At the same time, photographic portraits of the poor became popular among some who sought to advance the art of photography. There are some notorious examples of early photographers who were caught posing carefully selected models in deliberately misleading circumstances, demonstrating how the camera can be made to lie.

My small selection of paintings of country people from the nineteenth century is an attempt to show some that appear most faithful records that weren’t intended to support political views or attract praise at a Salon.

Jules Breton had been born and brought up in the rural village of Courrières, and returned there to paint intimate portraits of those who continued to live there, including this Young Girl Knitting, seen in 1860. Many of these intimate works were sold to private collectors and have never been seen at exhibition.

His portrait of this Mother Feeding her Baby from 1863 shows her wearing clogs, and clothing that has seen better days. She is feeding a very young baby in front of a frugal fire in what can only be her normal domestic conditions.

Jean-François Millet had been born in the village of Gruchy, and was the first child of a farming family. Although his portrait of A Norman Milkmaid at Gréville from 1871 lacks fine detail to reinforce its authenticity, she’s clearly grubby and wasn’t painted in the studio.

Max Liebermann’s The Preserve Makers from 1879 shows a shed full of country women preparing foodstuffs for bottling and canning; the latter gradually came into use after 1810, but didn’t become popular until the First World War. This shows well the light factory work that was introduced to country areas in the late nineteenth and early twentieth centuries, and the women who provided its labour force.

Pascal Dagnan-Bouveret’s An Accident from 1879 is an exception among these, in that it was not only submitted to the Salon of 1880, but won the artist a first-class medal. It was also supposedly painted from memory, showing an incident that the artist witnessed with a medical friend who was similarly called to assist with an injury.

Despite that, it shows a country doctor cleaning and bandaging the injured hand of a boy, as the rest of the extended family looks on. Conditions appear primitive: the small bowl of water is heavily blood-stained, and the cloth by it looks filthy. It’s also rich in detail that appears authentic, from the boy’s shoe compared with that of the doctor, to the bald man standing in front of a treasured grandfather clock in the right background.

Of Bastien-Lepage’s many portraits of country people, his Nothing Doing from 1882 appears the most convincing. From his unlaced mud-caked boots to his filthy and frayed waistcoat, this young agricultural worker looks the part. Bastien had spent his childhood in the village of Damvillers, although he was the son of a local artist. He frequently returned to his home village to paint local characters, such as this boy.

The young woman in Breton’s Song of the Lark (1884) has detailed features that appear true to life, in her bare feet with grubby and battered toenails, and hands that have seen hard work with the hook she holds.

Évariste Carpentier had been born into a farming family near the small town of Kuurne in Belgium. The Turnip Washer from 1890 is among the last of his thoroughly Naturalist paintings. Alongside the farmyard birds, two figures are busy washing piles of turnips in a small and dirty pond.

Throughout the career of Léon Augustin Lhermitte he painted the working lives of farmworkers and country people. In his pastel of The Farmworkers’ Supper from 1913, he shows those who have been working outdoors during the long day enjoying a meal at its end.

Together these paintings build a dispassionate image of a countryside that might have been lacking in worldly goods, but was hardly starved and pestilent. And, as I’ll show in the next and concluding article, at times rural life could still be idyllic.

Activity Monitor is one of the unsung heroes of macOS. If you understand how to interpret its rich streams of measurements, it’s thoroughly reliable and has few vices. When tuning for performance, it should be your starting point, a first resort before you dig deeper with more specialist tools such as Xcode’s Instruments or powermetrics.

How Activity Monitor works

Like Xcode’s Instruments and powermetrics, the CPU view samples CPU and GPU activity over brief periods of time, displays results for the last sampling period, and updates those every 1-5 seconds. You can change the sampling period used in the Update Frequency section of the View menu, and that should normally be set to Very Often, for a period of 1 second.

This was normally adequate for many purposes with older M-series chips, but thread mobility in M4 chips can be expected to move threads from core to core, and between whole clusters, at a frequency similar to available sampling periods, and that loses detail as to what’s going on in cores and clusters, and can sometimes give the false impression that a single thread is running simultaneously on multiple cores.

However, sampling frequency also determines how much % CPU is taken by Activity Monitor itself. While periods of 0.1 second and less are feasible with powermetrics, in Activity Monitor they would start to affect its results. If you need to see finer details, then you’ll need to use Xcode Instruments or powermetrics instead.

% CPU

Central to the CPU view, and its use in tuning for performance, is what Activity Monitor refers to as % CPU, which it defines as the “percentage of CPU capability that’s being used by processes”. As far as I can tell, this is essentially the same as active residency in powermetrics, and it’s vital to understand its strengths and shortcomings.

Take a CPU core that’s running at 1 GHz. Every second it ‘ticks’ forward one billion times. If an instruction were to take just one clock cycle, then it could execute a billion of those every second. In any given second, that core is likely to spend some time idle and not executing any instructions. If it were to execute half a billion instructions in any given second, and spend the other half of the time idle, then it has an idle residency of 50% and an active residency of 50%, and that would be represented by Activity Monitor as 50% CPU. So a CPU core that’s fully occupied executing instructions, and doesn’t idle at all, has an active residency of 100%.

To arrive at the % CPU figures shown in Activity Monitor, the active residency of all the CPU cores is added together. If your Mac has four P and four E cores and they’re all fully occupied with 100% active residency each, then the total % CPU shown will be 800%.

There are two situations where this can be misleading if you’re not careful. Intel CPUs feature Hyper-threading, where each physical core acquires a second, virtual core that can also run at another 100% active residency. In the CPU History window those are shown as even-numbered cores, and in % CPU they double the total percentage. So an 8-core Intel CPU then has a total of 16 cores, and can reach 1600% when running flat out with Hyper-threading.

The other situation affects Apple silicon chips, as their CPU cores can be run at a wide range of different frequencies according to control by macOS. However, Activity Monitor makes no allowance for their frequency. When it shows a core or total % CPU, that could be running at a frequency as low as 600 MHz in the M1, or as high as 4,512 MHz in the M4, nine times as fast. Totalling these percentages also makes no allowance for the different processing capacity of P and E cores.

Thus an M4 chip’s CPU cores could show a total of 400% CPU when all four E cores are running at 1,020 MHz with 100% active residency, or when four of its P cores are running at 4,512 MHz with 100% active residency. Yet the P cores would have an effective throughput of as much as six times that of the E cores. Interpreting % CPU isn’t straightforward, as nowhere does Activity Monitor provide core frequency data.

In this example from an M4 Pro, the left of each trace shows the final few seconds of four test threads running on the E cores, which took 99 seconds to complete at a frequency of around 1,020 MHz, then in the right exactly the same four test threads completed in 23 seconds on P cores running at nearer 4,000 MHz. Note how lightly loaded the P cores appear, although they’re executing the same code at almost four times the speed.

Threads and more

For most work, you should display all the relevant columns in the CPU view, including Threads and GPU.

Threads are particularly important for processes to be able run on multiple cores simultaneously, as they’re fairly self-contained packages of executable code that macOS can allocate to a core to run. Processes that consist of just a single thread may get shuffled around between different cores, but can’t run on more than one of them at a time.

Another limitation of Activity Monitor is that it can’t tell you which threads are running on each core, or even which type of core they’re running on. When there are no other substantial threads active, you can usually guess which threads are running where by looking in the CPU History window, but when there are many active threads on both E and P cores, you can’t tell which process owns them.

You can increase your chances of being able to identify which cores are running which threads by minimising all other activity, quitting all other open apps, and waiting until routine background activities such as Spotlight have gone quiet. But that in itself can limit what you can assess using Activity Monitor. Once again, Xcode Instruments and powermetrics can make such distinctions, but can easily swamp you with details.

GPU and co-processors

Percentages given for the GPU appear to be based on a similar concept of active residency without making any allowance for frequency. As less is known about control of GPU cores, that too must be treated carefully.

Currently, Activity Monitor provides no information on the neural processing unit (ANE), or the matrix co-processor (AMX) believed to be present in Apple silicon chips, and that available using other tools is also severely limited. For example, powermetrics can provide power use for the ANE, but doesn’t even recognise the existence of the AMX.

Setting up

In almost all cases, you should set the CPU view to display All processes using the View menu. Occasionally, it’s useful to view processes hierarchically, another setting available there.

Extras

Activity Monitor provides some valuable extras in its toolbar. Select a process and the System diagnostics options tool (with an ellipsis … inside a circle) can sample that process every millisecond to provide a call graph and details of binary images. The same menu offers to run a spindump, for investigating processes that are struggling, and to run sysdiagnose and Spotlight diagnostic collections. The Inspect selected process tool ⓘ provides information on memory, open files and ports, and more.

Explainers

Residency is the percentage of time a core is in a specific state. Idle residency is thus the percentage of time that core is idle and not processing instructions. Active residency is the percentage of time it isn’t idle, but is actively processing instructions. Down residency is the percentage of time the core is shut down. All these are independent of the core’s frequency or clock speed.

When an app is run, there’s a single runtime instance created from its single executable code. This is given its own virtual memory and access to system resources that it needs. This is a process, and listed as a separate entity in Activity Monitor.

Each process has a main thread, a single flow of code execution, and may create additional threads, perhaps to run in the background. Threads don’t get their own virtual memory, but share that allocated to the process. They do, though, have their own stack. On Apple silicon Macs they’re easy to tell apart as they can only run on a single core, although they may be moved between cores, sometimes rapidly. In macOS, threads are assigned a Quality of Service (QoS) that determines how and where macOS runs them. Normally the process’s main thread is assigned a high QoS, and background threads that it creates may be given the same or lower QoS, as determined by the developer.

Within each thread are individual tasks, each a quantity of work to be performed. These can be brief sections of code and are more interdependent than threads. They’re often divided into synchronous and asynchronous tasks, depending on whether they need to be run as part of a strict sequence. Because they’re all running within a common thread, they don’t have individual QoS although they can have priorities.