Dante has been rescued from three wild beasts by the ghost of Virgil, who leads him along the only possible route, taking them to the gate of Hell. Inscribed above that gate is a forbidding series of lines leaving the traveller in no doubt that they’re going to a place of everlasting pain and tortured souls. This culminates in the most famous line of the whole of the Divine Comedy:
Lasciate ogne speranza, voi ch’intrate
traditionally translated as Abandon hope all ye who enter here, but perhaps more faithfully as Leave behind all hope, you who enter, and is seen written in William Blake’s own hand below.

Virgil explains its meaning to Dante before the two enter. Dante is then struck by the terrible sounds that he hears, those of tormented sinners in Hell mixed with the noise of the first group of dead: those who have been refused entry to Hell or to Heaven, because of their cowardice in failing to choose between God and the Devil. They form a river of naked bodies drawn by a banner, their faces constantly stung by wasps and hornets, streaking them with blood and tears.

Among them is one who has been identified as Pope Celestine V, who resigned from office in 1294, and another candidate is Pontius Pilate, who refused to pass judgement on Christ.

Then Charon, an irascible old man with white hair and coal-black eyes, appears in his boat. He tells Dante to get away from the dead, as he won’t be carried across by him with those souls, and will have to arrange another crossing. Virgil intercedes to ensure that they too will be ferried across the marshy River Acheron to Hell.

Those souls destined for Hell rush to board the boat, with Charon sweeping them in using his oar to hit those who are slow. The boat then carries them across, as another load gathers on the shore ready for its return.

There is then a violent gust of wind and a red bolt of lightning, and Dante loses consciousness.

Although Dante doesn’t describe his crossing of the Acheron in Charon’s boat, this has been imagined by several painters.

In 1822, the young Eugène Delacroix painted one of his finest narrative works, The Barque of Dante, showing the pair crossing a stormy river Acheron in a very small boat. He painted this quickly, over an intense period of a little over two and a half months, just in time for submission to the Salon. Dante, wearing his distinctive scarlet chaperon (hat), holds his hand up as he leans back onto the shoulder of Virgil his guide. This has been interpreted as showing how, when we encounter challenges from the modern we should look to tradition for support.

This is one of the most remarkable paintings of the Inferno, as an early experiment with colour. In the detail below, water droplets on the bodies of those surrounding the boat contain at least three different colours: their reflected highlights are pure white, the rest of the body of the droplet and its trail are the dark green of the water below, and the droplet itself has a shadow of the same pink that Delacroix uses to shade flesh. Their overall effect is of an unusually three-dimensional and realistic droplet.

The artists

José Benlliure y Gil (1855–1937) was a Spanish painter who was born in Valencia but spent much of his working life in Rome, where he became the director of the Spanish Academy there. After painting small genre works, he turned to classical narratives including the painting shown here.

William Blake (1757–1827) was a British visionary painter and illustrator whose last and incomplete work was an illustrated edition of the Divine Comedy for the painter John Linnell. Most of his works shown in this series were created for that, although he did draw and paint scenes during his earlier career. I have a major series on his work here.

Eugène Delacroix (1798–1863) was a major French painter whose Romantic and painterly style laid the groundwork for the Impressionists. In addition to many fine easel works, he painted murals and was an accomplished lithographer too. Many of his paintings are narrative, and among the most famous is Liberty Leading the People from 1830. This article introduces a series featuring his major works.

Gustave Doré (1832–1883) was the leading French illustrator of the nineteenth century, whose paintings are still relatively unknown. Early in his career, he produced a complete set of seventy illustrations for translations of the Inferno, first published in 1857 and continue to be used. These were followed in 1867 by more illustrations for Purgatorio and Paradiso. This article looks at his paintings.

Alexander Dmitrievich Litovchenko (1835-1890) was born in Kremenchuk, Ukraine, but spent most of his career painting historical events in Russia. His painting of Charon won him a gold medal.

Paolo Vetri (1855–1937) was a precocious Italian painter who was born in Sicily. He was a pupil of the great narrative artist Domenico Morelli, and completed several major murals as well as many easel paintings.

References

Wikipedia
Danteworlds

Robin Kirkpatrick (trans) (2012) Dante, The Divine Comedy, Inferno, Purgatorio, Paradiso, Penguin Classics. ISBN 978 0 141 19749 4.
Richard Lansing (ed) (2000) The Dante Encyclopedia, Routledge. ISBN 978 0 415 87611 7.
Guy P Raffa (2009) The Complete Danteworlds, A Reader’s Guide to the Divine Comedy, Chicago UP. ISBN 978 0 2267 0270 4.
Prue Shaw (2014) Reading Dante, From Here to Eternity, Liveright. ISBN 978 1 63149 006 4.

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

1: Successor to 3 inside a scheme was part of a popular atelier.

2: High speed subatomic particle took the lead in the 1990s.

3: Creator of a squire’s assistant was the first, but died before Mac OS X.

The common factor

I look forward to your putting alternative cases.

With additional information about Spotlight’s volume indexes, this article looks in more detail at how those indexes are updated when new files are created, and how local search is reflected in log entries. To do this I use the Spotlight test feature in my free utility Mints, which is designed to assess its performance.

Mints can create a test folder and populate it with 9 test files, copied from inside the app bundle using File Manager’s copyItem function. Provided the app and that newly created folder in ~/MintsSpotlightTest4syzFiles are in the same volume, this will almost certainly occur by creating APFS clone files. The files are:

• SpotTestA.rtf, RTF, relying on /System/Library/Spotlight/RichText.mdimporter
• SpotTestB.pdf, PDF, relying on /System/Library/Spotlight/PDF.mdimporter
• SpotTestC.txt, plain text, relying on /System/Library/Spotlight/RichText.mdimporter
• SpotTestD.html, HTML, relying on /System/Library/Spotlight/RichText.mdimporter
• SpotTestE.docx, Microsoft Word docx, replying on /System/Library/Spotlight/Office.mdimporter
• SpotTestEXIF.jpg, JPEG image not containing the target string in the image, but in the Make field of its EXIF IDF0 metadata, and relying on /System/Library/Spotlight/Image.mdimporter
• SpotTestF.numbers, Numbers spreadsheet containing the target string in one of its cells, and relying on /System/Library/Spotlight/iWork.mdimporter
• SpotTestG.pages, Pages document, relying on /System/Library/Spotlight/iWork.mdimporter
• SpotTestMD.txt, plain text not containing the target string in its contents, but in an extended attribute of type com.apple.metadata:kMDItemKeywords attached when the file is copied.

The search target they each contain is a string starting with the characters syzygy999 so most likely to be unique to the test files and Mints’ bundle.

This example test was performed on a Mac mini M4 Pro running macOS 15.6 from its internal SSD, with the Home folder located in the boot Data volume in that storage.

Indexing

Folder creation and file copying should take place soon after clicking on the Create Test button, in this example test in just over 0.3 seconds. The first mdworker process responding to this is spawned about 0.9 seconds after file copying starts, and further mdworker processes are added to it, making a total of 11. These are uncorked by launchd in about 0.03-0.05 seconds and are active for a period of about 0.2 seconds before they appear to have finished creating new posting lists to be added to the local indexes.

Shortly after those are complete, spotlightknowledge is active briefly, then 0.2 seconds after file copying mediaanalysisd receives a text processing request and initialises CGPDFService. Just over 0.1 second later CoreSceneUnderstanding is invoked from mediaanalysisd. For the following 5 seconds, a series of MADTextEmbedding (mediaanalysisd text embedding) tasks are performed. Finally, content obtained by mdworker and MADTextEmbedding is compressed by mds_stores, finishing about 6.7 seconds after the new files were created.

These steps are summarised in the diagram above, where those in blue update metadata indexes, and those in yellow and green update content indexes. It’s most likely that each file to be added to the indexes has its own individual mdworker process that works with a separate mdimporter, although in this case at least 11 mdworker processes were spawned for 9 files to be indexed.

Text extraction from files by mediaanalysisd involves a series of steps, and will be covered in more detail separately. In this test, local Spotlight indexes should have been updated within 7-8 seconds of file creation, so waiting at least 10 seconds after clicking the Create Test button should be sufficient to enable the test files to be found by search.

Searching

When the Check Search button in Mints is clicked, an NSMetadataQuery is performed using a search predicate over the search scope of NSMetadataQueryUserHomeScope, the Home folder. This uses the search predicate (kMDItemTextContent CONTAINS[cd] "syzygy999") OR (kMDItemKeywords CONTAINS[cd] "syzygy999") OR (kMDItemAcquisitionMake CONTAINS[cd] "syzygy999") to find all items containing any of:

• kMDItemTextContent CONTAINS[cd] "syzygy999" looks for the target string in a text representation of the content of the document, as in most of the test files used.
• kMDItemKeywords CONTAINS[cd] "syzygy999" looks for keywords in an extended attribute of type com.apple.metadata:kMDItemKeywords as attached to the SpotTestMD.txt file.
• kMDItemAcquisitionMake CONTAINS[cd] "syzygy999" looks for the Make field of an EXIF IDF0 as embedded in the SpotTestEXIF.jpg file.

Each of those is both case- and diacritic-insensitive, although the test cases all use lower case without any diacritics.

Remarkably little is recorded in the log for these test searches. com.apple.metadata starts the query within 0.001 second of clicking the Check Search button, and is interrupted by TCC approving the search to proceed. About 0.03 seconds after the start of the query, a series of entries from mds_stores reports query node counts of 4, and results are fetched and sent as replies between 0.09 and 19.5 seconds after the start of the query. However, Mints typically reports a considerably shorter search time of around 4 seconds.

Better testing

The test currently included in Mints appears useful, in that it assesses the whole of Spotlight local search from file creation to completion of a test search. However, in its current form it doesn’t test LiveText or other in-image text extraction, and only applies to the volume containing the Home folder. Log extracts obtained in its Log Window are basic and don’t capture much of the detail used for this article. There seems scope for a dedicated Spotlight test app that addresses these and more.

Summary

• Spotlight local indexing from the creation of nine new files reliant on macOS bundled mdimporters is initiated promptly, and should be completed within 10 seconds of their creation. It appears to follow the scheme shown in the diagram above.
• Text extraction from images by mediaanalysisd (‘MAD’) is significantly slower than extraction of metadata and other text content.
• NSMetadataQuery search should also be relatively quick when the number of hits is small, but leaves little information in the log.

Until the advent of chemistry in the eighteenth century, early in the Age of Enlightenment, the vast majority of pigments occurred in nature, even if the minerals or plant matter from which they were derived had to be specially processed. The first truly synthetic pigment was so ancient that it had been forgotten completely by the Middle Ages: Egyptian blue was originally made before about 3000 BCE by heating together powdered rocks and sand, but that was an exception. It wasn’t until the early years of the eighteenth century that a hydrated iron hexacyanoferrate complex soon known as Prussian blue was synthesized.

No one knows who first made Prussian blue, nor exactly when it was first synthesized. It seems to have appeared initially around 1704, and its origins have been attributed variously to Diesbach in Berlin, or Mak in Leipzig. For once its name is appropriate, as it was a product of the Prussian Empire. Its potential as a colourant was recognised by 1710 when it went on sale in Berlin, and by about 1724 it was being manufactured across Europe.

Among the earliest surviving oil paintings to use Prussian Blue is that by Adriaen van der Werff and Henrik van Limborch, of Jacob Blessing the Sons of Joseph. This was started by van der Werff before he died in 1722, and the paint containing Prussian blue pigment is thought to have been applied by him to the curtain at the upper left. After van der Werff’s death, his pupil Henrik van Limborch finished the painting between 1727-28.

Another early example of the proven use of Prussian blue is Antoine Watteau’s The Italian Comedians from about 1720.

Canaletto is one of the first Masters to have used the new pigment extensively. Grand Canal from Palazzo Balbi toward the Rialto from 1720-23 has been attributed to him as one of his earliest surviving works, and its blues have been found to contain Prussian blue.

Canaletto was quick to adopt the pigment for use in almost all his paintings, including this view of the Rio dei Mendicanti from 1723-24, above, and his famous The Stonemason’s Yard (c 1725), below.

As experience was gained in using this pigment, it became controversial. Some artists were confident that its colour was stable and didn’t change or fade, but others experienced problems as bad as or even worse than those of the notoriously fugitive indigo blue, which it had generally replaced. It has gradually become understood that adverse results of lightfastness testing (and experience in paintings) have depended on the mixture of Prussian blue with other colours, particularly with white paint, and the presence of impurities in the pigment.

By the middle of the eighteenth century, Prussian blue was widely used with a range of binding media, with the notable exception of fresco and other alkaline media with which it proved incompatible.

William Hogarth’s paintings in his Marriage A-la-Mode series have been found to contain both smalt and Prussian blues. In The Tête à Tête (c 1743), smalt has been found in the ornate carpet, and I suspect that the ornamental pillars behind the woman rely on Prussian blue, at least in part. Hogarth trained as Prussian blue came to the ascendant, and wouldn’t have painted much before it had become widely available.

Jean-Baptiste Perronneau’s A Girl with a Kitten from about 1743 is a fine example of the use of Prussian blue in pastels: the girl’s blue dress and the background have both been found to contain the pigment.

Prussian blue also became popular in water-based media. William Blake’s Lucia Carrying Dante in his Sleep, from his series depicting Dante’s Divine Comedy painted in watercolour between 1824-27, is a good example. In this and several other of his paintings, Blake used the pigment on its own and mixed with gamboge yellow in what was known as Prussian green.

Prussian blue pigment has been found in the blue passages in Whistler’s The Princess from the Land of Porcelain (1863-65), from his Peacock Room, shown above and in the detail below.

The use of different blue pigments varied markedly among the French Impressionists and their successors. Paul Cézanne and Georges Seurat appear to have used Prussian blue seldom if at all, but it’s well known in the work of Edgar Degas, Claude Monet and Vincent van Gogh.

Although Monet’s Bathers at la Grenouillère (1869) contains cobalt blue in the brighter mid-blues of the water surface and details in the boats, darker blues towards the left, and in the clothing of some of the figures and their reflections, are almost certainly Prussian blue.

Vincent van Gogh’s portrait of La Mousmé from 1888 illustrates some of the difficulties of identifying pigment use. Its unusual title is derived from the Japanese word musume, meaning girl; at the time the French word was understood to mean an ‘easy’ girl.

Infra-red images demonstrate van Gogh’s use of at least two different blues, one of which has been identified as Prussian blue. The two (or more) blue pigments aren’t distributed evenly: on the girl’s jacket, the three blue stripes to the left of the row of buttons contain the most Prussian blue, while the three under her right armpit, which look darker, contain little or no Prussian blue. Van Gogh also mixed yellow with Prussian blue to form the green of the flowers she holds in her hand.

Prussian blue remained a popular pigment in oil and watercolour paints well into the twentieth century, and is still offered in commercial ranges. For many artists, though, it has been replaced by much more recent synthetic blue pigments, such as phthalocyanine (‘phthalo’) blue, introduced around 1970, and is seldom used in Prussian green.

Reference

Barbara H Berrie (1997) Artists’ Pigments, vol 3, ed Elisabeth West Fitzhugh, Archetype. ISBN 978 1 904982 76 0.

One thing we humans are good at is searching. It’s a task we engage in from a few moments after birth until the time we slip away in death, we search everything around us. Locating and identifying that bird of prey wheeling high, finding the house keys, and that book we mislaid some time last week, meeting the perfect partner, discovering the right job, choosing the best education, looking through a Where’s Wally? or Where’s Waldo? book, and so on. Searching has transformed some into explorers like Christopher Columbus, and was the purpose of the chivalric quest. It’s what researchers in every field do, and thanks to Douglas Adams can be answered by the number 42.

Last week my searching took two new turns.

Spotlight

The first was more of a meta-search, in trying to discover more about the internals of Spotlight. Following the example of Maynard Handley, who has used them so successfully in understanding how M-series CPUs work, I looked through patents that have been awarded to Apple for the work of its search engineers. Yesterday’s slightly fuller history of Spotlight search is one result, and there are more to come in the future as I digest those patents concerned with performing search.

There’s a tinge of irony here, as many of my searches have been conducted using Google Patents, alongside Google Scholar one of the remaining search engines that doesn’t yet use AI and attempt to provide its own answers.

Logs

The other marks a new phase in my quest to get more information from the Unified log. Looking back to my first comment here, I realise how wildly over-optimistic I was when I wrote that it “should make my life a lot easier”, and that “a new version of Console will provide improved features to help us wade through logs.” Nine years later, I look wistfully at what remains of Console and realise how wrong I was on both counts.

When RunningBoard arrived in macOS Catalina, I soon noticed how “its log entries are profuse, detailed, and largely uncensored for privacy.” Since then it has proved garrulous to the point where its apparently ceaseless log chatter is a distraction, and can overwhelm attempts to read other log entries. I suspect it has contributed significantly to those advanced Mac users who now refuse to even try to make sense of the log.

One answer might be to tweak log preferences to shut out this noise, but given the purpose of RunningBoard in monitoring the life cycle of apps, why not try to use the information it provides? To do that, it’s first necessary to understand RunningBoard’s idiosyncratic language of assertions, and its protocols under which they’re acquired. The only way to do that without documentation is by observation: catalogue over 30 of those assertions for an interesting example like Apple’s Developer app, and see what they reveal.

By far the most informative entries from RunningBoard are those announcing that it’s acquiring an assertion, such as
Acquiring assertion targeting [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] from originator [osservice<com.apple.uikitsystemapp(501)>:748] with description <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:424-748-2228 target:2946 attributes:[
<RBSDomainAttribute| domain:"com.apple.frontboard" name:"AfterLife-Subordinate" sourceEnvironment:"(null)">
]>

In a log often censored to the point of being unintelligible, this contains frank and explicit detail. The app is identified clearly, with the user ID of 501 and process ID of 2946. The originator is similarly identified as com.apple.uikitsystemapp with its PID of 748, which is confirmed in the middle digits in the Assertion ID. This is explicitly related to FrontBoard and an attribute named AfterLife-Subordinate. There’s not a single <private> to blight this entry, although further knowledge is needed to decode it fully.

Normally to get such information from a running process would require its source code to be instrumented with calls to write log entries, many of which would be lost to <private>, yet RunningBoard seems happy, for the moment, to provide that information freely. You can see what I mean by applying the predicate
subsystem == "com.apple.runningboard" AND message CONTAINS "Acquiring assertion t"
in LogUI, to obtain a running commentary on active apps and processes. Once you’ve identified a relevant assertion, you can focus attention on other log entries immediately prior to that. I will be following this up in the coming week, with fuller instructions and some demonstrations.

Although neither patents nor assertions have the significance of the number 42, in their own ways they show how the art and science of search aren’t dead yet, nor have they succumbed to AI.

Blue pigments used in painting include some of the oldest used by man, and others that led the change to modern synthetic pigments driven by the arrival of chemistry in the eighteenth century. This weekend I look at two examples, today the queen of pigments, ultramarine, and tomorrow the first synthetic chemical, Prussian blue.

Originally made by crushing and grinding the semi-precious stone lapis lazuli, the cost of ultramarine has exceeded that of gold. Seen in paintings, it produces a rich slightly reddish blue which stands the test of time, as distinctive and effective today as when it was first used. And its use has a history of unmasking fakes and forgeries.

The sole source of lapis lazuli in Europe and the West were quarries in Badakshan, described by Marco Polo and now in Afghanistan. It appears that wall paintings made around 507-554 CE adjacent to the great Buddahs of Bamiyan were the first to have used the mineral as a pigment. It was then used in early Persian miniatures, and in early Chinese and Indian paintings too. Tragically, these wall paintings in Bamiyan, Afghanistan, were damaged by the Taliban in 2001 when the two statues were destroyed, and their restoration has made little progress since.

The powdered pigment had made its way, first along the Silk Road, then by sea, to traders in Venice by about 1300. By the Renaissance, it was established as one of the most important and precious of all the pigments used in European art.

Because of its beauty and high cost, ultramarine blue was used for the robes of Jesus Christ and the Virgin Mary. Duccio’s panels from the Maestà Predella, including this of The Healing of the Man born Blind, show this tradition in its earliest years, around 1307-11. As a pigment, it proved practical in egg tempera as here, and in oils, watercolour, and fresco.

Ultramarine blue has been found in the van Eyck brothers’ Ghent Altarpiece from about 1432 (above), and particularly in its most famous panel, The Mystic Lamb, below.

Sandro Botticelli’s early tempera on panel painting Adoration of the Kings from about 1470, apparently made with Filippino Lippi, shows two different blue colours and purple. He painted the purple with an opaque underpainting of lead white tinted with a red lake derived from madder, to create pink. That was then glazed with quite coarse particles of ultramarine blue, so the pigment was thinly dispersed.

Peter Paul Rubens used ultramarine blue widely in his magnificent triptych now in Antwerp Cathedral. In its centre panel, Descent from the Cross (1612-14), it has been found combined with indigo and other pigments.

In van Dyck’s Charity from 1627-8, its most obvious use is in the blue cape, where ultramarine blue was painted over indigo, applied as both a tint and as a glaze over the top.

Visit any of the larger galleries with substantial collections of paintings made before 1700, and you will see works with drapery that I can only describe as arresting in the brilliance of their ultramarine blue. One stunning example in the National Gallery in London is Sassoferrato’s The Virgin in Prayer from 1640-50. The Virgin’s cloak looks as if it was painted only yesterday, and that colour makes you stop in your tracks and draws you into the painting, like no other pigment can.

Given its importance, and limited supply, considerable effort was devoted to ensuring that natural ultramarine blue was of the highest quality, and alternative sources were sought. Deposits in the Chilean Andes, and near Lake Baikal in Siberia, weren’t developed until the nineteenth century, and attempts to make synthetic ultramarine proved unsuccessful until 1828, when Jean Baptiste Guimet was awarded a prize of six thousand francs for his discovery. Almost simultaneously, C G Gmelin of Tübingen discovered a slightly different method.

Commercial production had started by 1830, and it became known as French ultramarine, to distinguish it from the natural pigment. Although almost identical in colour and performance, there are significant differences between natural and synthetic ultramarine when tested in the laboratory. This has enabled the examination of paintings to determine the source of their pigment, and has brought some surprises. These most often relate to later overpainting during restoration. For example, two areas of much later painting have been discovered in the van Eycks’ Ghent Altarpiece.

Examination of Édouard Manet’s Corner of a Café-Concert, from 1878-80, has shown that he used synthetic ultramarine in its blue passages, for example.

Pierre-Auguste Renoir’s The Umbrellas, from about 1881-86, uses synthetic ultramarine in a methodical fashion. The first stage in its painting used only cobalt blue, but in its second stage synthetic ultramarine was applied extensively.

Vincent van Gogh’s A Wheatfield, with Cypresses (1889) contains synthetic ultramarine in its deepest blues, and in some areas of green, although it’s unusual to find ultramarine mixed to form green. Before synthetic pigment became available, this would have been far too expensive a way of making any significant amount of green, but once much cheaper pigment came onto the market, that became more feasible, if still unusual.

The ability to distinguish synthetic ultramarine, which didn’t exist before about 1828, and the natural pigment has proved important in detecting some forgeries. Only the most ignorant would attempt to pass off a painting made with synthetic ultramarine as being very old, but a few fakes fell at that hurdle.

Han van Meegeren was far too knowledgeable and cunning to be caught so easily. He used natural ultramarine, for example when he sold The Men at Emmaus (1937) to the Museum Boijmans Van Beuningen as a Vermeer. What no one knew at the time was that his ultramarine looked genuine, but had been contaminated with a small amount of cobalt blue, which wasn’t discovered until 1803-04, and was first used as a pigment in 1806.

In 1960, the modern artist Yves Klein worked with the paint supplier Edouard Adam to ‘invent’ a paint he termed International Klein Blue (IKB). Although its formulation is a secret, it’s almost entirely synthetic ultramarine blue pigment in a polyvinyl acetate binder.

Like all the best queens, ultramarine blue has an unnerving habit of revealing the truth.

Reference

Joyce Plesters (1993) Artists’ Pigments, vol 2, ed Ashok Roy, Archetype. ISBN 978 1 904982 75 3.

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

1: Successor to 3 inside a scheme was part of a popular atelier.

2: High speed subatomic particle took the lead in the 1990s.

3: Creator of a squire’s assistant was the first, but died before Mac OS X.

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.

Since writing A brief history of local search, I have come across numerous patents awarded to Apple and its engineers for the innovations that have led to Spotlight. This more detailed account of the origins and history of Spotlight uses those primary sources to reconstruct as much as I can at present.

1990

ON Technology, Inc. released On Location, the first local search utility for Macs, a Desk Accessory anticipating many of the features to come in Spotlight 15 years later. This indexed text found in the data fork of files, using format-specific importer modules to access those written by Microsoft Word, WordPerfect, MacWrite and other apps of the day. Those files and their indexed contents were then fully searchable. This required System Software 6.0 or later, and a Mac with a hard disk and at least 1 MB of RAM. It was developed by Roy Groth, Rob Tsuk, Nancy Benovich, Paul Moody and Bill Woods.

1991

Version 2 of On Location was released. ON Technology was later acquired by Network Corporation, then by Symantec in 2003.

1994

AppleSearch was released, and bundled in Workgroup Servers. This was based on a client-server system running over AppleShare networks. September’s release of System Software 7.5 introduced a local app Find File, written by Bill Monk.

1998

Sherlock was released in Mac OS 8.5. This adopted a similar architecture to AppleSearch, using a local service that maintained indexes of file metadata and content, and a client app that passed queries to it. This included remote search of the web through plug-ins working with web search engines, as they became available.

Early patent applications were filed by Apple’s leading engineers who were working on Sherlock, including US Patent 6,466,901 B1 filed 30 November 1998 by Wayne Loofbourrow and David Cásseres, for a Multi-language document search and retrieval system.

1999

Sherlock 2 was released in Mac OS 9.0. This apparently inspired developers at Karelia Software to produce Watson, ‘envisioned as Sherlock’s “companion” application, focusing on Web “services” rather than being a “search” tool like Sherlock.’

2000

On 5 January, Yan Arrouye and Keith Mortensen filed what became Apple’s US Patent 6,847,959 B1 for a Universal Interface for Retrieval of Information in a Computer System. This describes the use of multiple plug-in modules for different kinds of search, in the way that was already being used in Sherlock. Drawings show that it was intended to be opened using an item on the right of the menu bar, there titled [GO-TO] rather than using the magnifying glass icon of Sherlock or Spotlight. This opened a search dialog resembling a prototype for Spotlight, and appears to have included ‘live’ search conducted as letters were typed in.

2001

Karelia Software released Watson.

2002

Mac OS X Jaguar brought Sherlock 3, which many considered had an uncanny resemblance to Watson. That resulted in acrimonious debate.

2005

In preparation for the first Intel Macs, Mac OS X 10.4 Tiger, released in April 2005, introduced Spotlight as a replacement for Sherlock, which never ran on Intel Macs.

Initially, the Spotlight menu command dropped down a search panel as shown here, rather than opening a window as it does now.

2006

On 4 August, John M Hörnkvist and others filed what became US Patent 7,783,589 B2 for Inverted Index Processing, for Apple. This was one of a series of related patents concerning Spotlight indexing. Just a week later, on 11 August, Matthew G Sachs and Jonathan A Sagotsky filed what became US Patent 7,698,328 B2 for User-Directed search refinement.

A Finder search window, precursor to the modern Find window, is shown in the lower left of this screenshot taken from Tiger in 2006.

2007

Spotlight was improved in Mac OS 10.5 Leopard, in October. This extended its query language, and brought support for networked Macs that were using file sharing.

This shows a rather grander Finder search window from Mac OS X 10.5 Leopard in 2009.

2014

Search attributes available for use in the search window are shown here in OS X 10.9 Mavericks, in 2014.

In OS X 10.10 Yosemite, released in October, web and local search were merged into ‘global’ Spotlight, the search window that opens using the Spotlight icon at the right end of the menu bar, accompanied by Spotlight Suggestions.

2015

John M Hörnkvist and Gaurav Kapoor filed what was to become US Patent 10,885,039 B2 for Machine learning based search improvement, which appears to have been the foundation for Spotlight Suggestions, in turn becoming Siri Suggestions in macOS Sierra. Those were accompanied by remote data collection designed to preserve the relative anonymity of the user.

This shows a search in Global Spotlight in macOS 10.12 Sierra, in 2017.

c 2019

Apple acquired Laserlike, Inc, whose technology (and further patents) has most probably been used to enhance Siri Suggestions. Laserlike had already filed for patents on query pattern matching in 2018.

I’m sure there’s a great deal more detail to add to this outline, and welcome any additional information, please.

4 August 2025: I’m very grateful to Joel for providing me with info and links for On Location, which I have incorporated above.

Between the Middle Ages and the twentieth century there have been three periods in which European painting has changed dramatically: in the Renaissance, the Dutch Golden Age, and the nineteenth century. Of those, the Renaissance is usually viewed as the most important. In this series, I make the case for paintings of the Dutch Golden Age being more revolutionary than those of the Renaissance, and bringing greatest change.

The Low Countries, covering what’s currently the Netherlands, Belgium, Luxembourg and parts of north-eastern France, had been a patchwork of small duchies and other states under the overall rule of the Holy Roman Emperor. In 1568-1579, seven of the more northerly provinces revolted to form their own Dutch Republic with the Union of Utrecht.

These are shown in red, orange and yellow in this map. Centres of art in the Dutch Republic included The Hague, its de facto capital, Utrecht, Leiden, Delft, Harlem, and Amsterdam. To the south were the lands composing the Spanish Netherlands, notably Flanders and Brabant, including the cities of Antwerp and Brussels. Thus, Peter Paul Rubens who worked from his workshop in Antwerp until his death in 1640 was Flemish, while Rembrandt who was brought up in Leiden and worked in Amsterdam until his death in 1669 was one of the leading artists of the Dutch Republic.

Although the Dutch Republic existed between 1579-1795, the period known as its Golden Age is generally agreed as ending in around 1672, with the French invasion, and its start in art is usually delayed to around 1600. During that period of seventy years the provinces flourished, with extensive colonies overseas and rich trade with them and throughout Europe. The population of 1 to 1.5 million grew prosperous, with rising disposable income.

Society was liberal, with a high degree of religious tolerance and high immigration. Religious and ethnic minorities who were being oppressed in other parts of Europe were welcomed in the Republic, and the city of Amsterdam became a centre for migrants. This encouraged an increasingly learned society, with innovative science and academic institutions, rising literacy, and flourishing arts.

Paintings became popular possessions across much of Dutch society, and were sold in the first art fairs and by dealers, rather than being commissioned through a system of patronage. Few wall paintings were made in this period, and paintings of the Dutch Golden Age are almost exclusively ‘easel’ paintings, most of them relatively small so they didn’t require a large mansion for their exhibition.

Training of painters remained based on apprenticeships in workshops, and there was no academy system to stifle creativity. Once trained, masters joined their local Guild of Saint Luke and were able to establish their own workshop. Prices remained low so paintings were affordable by almost everyone. Production was extraordinary, with estimates of more than a million paintings being produced in a twenty-year period, and possibly as many as five million in the whole period of seventy years.

This resulted in the rapid development of new genres and themes in addition to those established by the Renaissance, and this is probably the most enduring effect of the Dutch Golden Age on European painting.

Portraits extended beyond those of single patrons or their close families.

Rembrandt painted his Anatomy Lesson of Dr. Nicolaes Tulp in 1632, as an early commission soon after his arrival in Amsterdam. It’s a group portrait of distinguished members of the Surgeons’ Guild in their working environment. Another novel sub-genre was the group portrait of a section of the local militia, best-known now from Rembrandt’s huge Night Watch from 1642.

Painting other humans was extended to cover their livestock and other animals.

Paulus Potter, who became a member of the Guild of Saint Luke in Delft in 1646 founded the new genre of animal painting with his nearly life-size portrait of The Bull the following year. Beyond the animals here is the church of Rijswijk, between Delft and The Hague.

The tentative landscapes that had started to appear in the Renaissance flourished into what was probably the most popular genre of all.

Dutch landscape artists quickly realised that, even if they had relatively little earth and water to depict, the heavens above could be equally interesting. Horizons fell rapidly down their paintings, as seen in Jan van Goyen’s View of Dordrecht with the Grote Kirk Across the Maas from 1644.

Some painters, including Jacob van Ruisdael, turned their canvases to make portraits of towering clouds, as in his View of Haarlem with Bleaching Fields from about 1665. The distant town of Haarlem with its monumentally large church of Saint Bavo – works of man – is dwarfed by these high cumulus clouds, the works of God. This motif proved so popular that Van Ruisdael painted many variants of the same view, making it now one of the most widespread landscapes across the galleries of Europe.

Although Adriaen van de Velde from Amsterdam went on to paint farm animals, his early beach scenes, including The Beach at Scheveningen (1658), broke new ground that a century earlier would have seemed inconceivable in a painting. Others turned their attention to the rapidly growing cities.

Gerrit Berckheyde’s view of Groote Market in Haarlem, Amsterdam from 1673 shows one the largest of the city’s marketplaces at the end of the Golden Age.

Paintings of the Flemish Renaissance had often explored the optical properties of surfaces. These continued in the development of another new genre, that of still life.

Clara Peeters trained in Antwerp, then painted an outstanding series of still lifes in the Dutch Republic. Among those is her still life with Cheeses, Almonds and Pretzels from about 1615, a celebration of the very earthly sensuous pleasures of food.

Ambrosius Bosschaert painted this Flower Still Life in oil on copper in 1614. At first its eclectic mixture of different flowers and flying insects might appear haphazard. However, the flowers include carnation, rose, tulip, forget-me-nots, lilies of the valley, cyclamen, violet and hyacinth, which could never (at that time) have been in bloom at the same time. The butterflies, bee and dragonfly are as ephemeral as the flowers around them, suggesting that this has an underlying vanitas theme.

The son a of Flemish immigrant, David Bailly, who lived and painted in Leiden, painted this Self-Portrait with Vanitas Symbols in 1651, with its multiple portraits referring to the past. The figure shows him as a much younger man, holding the maulstick he used in painting. His actual self-portrait at the time is in the painting he is holding with his left hand. Next to that is a painting of his wife, who had already died, and a ghostly image of her is projected onto the wall behind the wine glass.

Gathered in front of the artist are ephemera and other signs of vanitas: the snuffed-out candle, a glass of wine, flowers, and soap bubbles, together with a string of pearls and a skull. If that message is not clear enough, he provides the quotation on a piece of paper: vanitas vanitum et omnia vanitas, together with his signature and date.

Of all the genres that flourished in the Golden Age, it was painting everyday life, now generally referred to as genre painting, that was most novel and popular.

Long before its value in preventing scurvy was realised (in 1747), or it was carbonated even later, still cloudy lemonade had become a popular soft drink. The extensive trade links of the Dutch Republic made the drink available to the middle classes, as celebrated in Gerard ter Borch’s The Glass of Lemonade (1655-60).

A fashionably-dressed young man is helping to prepare a glass of lemonade for a young woman, who is equally open about her love of fashionable clothing. Behind her is the woman’s nurse or maid, who is having to comfort her through the excitement of the experience. They are surrounded by a contemporary Dutch interior, with the inevitable bed lurking in the dark at the right.

It’s easy to mistake Pieter de Hooch’s A Woman Drinking with Two Men from about 1658 for a Vermeer, and like the latter he decorates the far wall with a contemporary map. The Eighty Years’ War had not long ended, and the Dutch Republic was flourishing. Discarded objects are scattered on its black-and-white tiled floor. There’s a large and empty fireplace, and above it hangs a religious painting.

I hope you’ll join me in the coming weeks as I explore how painting flourished and changed in the Dutch Golden Age.

We’re now into August, Apple has released the last substantial updates to macOS before the arrival of Tahoe, so where does macOS stand now?

macOS Sequoia has just had its last scheduled update to 15.6 before it’s expected to enter the first of its two years of security-only updates. The main benefits of this update are an important fix to restoring Macs in DFU mode using either the Finder or Apple Configurator, and its long list of security updates, 81 vulnerabilities in total. If you’re already running Sequoia, it’s an important update.

Sequoia is fully supported on the following Macs:

• iMac 2019, all T2 iMacs including iMac Pro from 2017
• MacBook Air 2020 and later, but not 2018 or 2019
• MacBook Pro 2018 and later (all T2 models)
• Mac mini 2018 and later
• Mac Pro 2019 and later
• all Apple silicon Macs.

macOS Sonoma is now entering its second and final year of security-only updates, and in the latest to 14.7.7 has around 50 vulnerabilities fixed. Although that’s a lot less than in 15.6, those are still important if you’re staying with Sonoma for the time being.

Sonoma is fully supported on the following Macs:

• iMac 2019
• all Intel Macs with T2 chips
• all Apple silicon Macs.

macOS Ventura has probably had the last of its security updates, although in the past Apple has sometimes released one more update in the autumn/fall. Its latest update to 13.7.7 has around 41 vulnerabilities fixed, making it essential if your Mac can’t be upgraded to Sonoma or later. If your Mac is supported by Sonoma, now is the time to plan upgrading it so that it can continue receiving security updates from September.

Tahoe

macOS Tahoe has now entered the public phase of its beta-testing, with the fourth version provided to developers. While much of the debate surrounds its Liquid Glass and new look, it does bring new features such as a Phone app to Macs. So far it appears internally stable and doesn’t look likely to be delayed for major bugs to be wrangled.

Tahoe is fully supported on the following Macs:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

Although the first couple of versions of Tahoe presented themselves to older apps and scripts as macOS 16, since beta 3 it has been thoroughly macOS 26 regardless of how it’s asked. As this hasn’t been mentioned in Apple’s release notes, it’s unclear what it will do in the final release. If you have apps or scripts that could break when they discover the version of macOS running is 26, now is the time to send Apple feedback to make your case for it to report as version 16.

Older Macs

Open Core Legacy Patcher, OCLP, is being updated in the hope that it will be able to run macOS Tahoe on at least some unsupported models, although that probably won’t be available until the end of this year. You can follow progress here, where you’ll see some of the challenges its developers are facing. Another site worth watching is Mr. Macintosh on YouTube.

Next stop, probably in September, should be:

• macOS 26.0 Tahoe
• macOS 15.7 Sequoia
• macOS 14.8 Sonoma

if Apple remains consistent with previous numbering. Farewell to Ventura, old friend!

At one time, many churches across northern Europe were constructed using load-bearing wooden posts termed staves, hence are known as stave churches. It’s thought that in Norway alone there used to be as many as two thousand. As they were built of wood rather than stone, fire was a danger, and between those that burned down and others that were replaced by more modern structures, there are now only thirty-one original stave churches remaining, all except three being in Norway. They have seldom been painted, and in this article I show paintings known to depict real churches from two Norwegian artists, and a relative from the Carpathian Mountains in Ukraine.

JC Dahl’s Landscape in Kaupanger with a Stave Church from 1847 employs a little deception as the real church at Kaupanger had been modified structurally and looked quite different at the time. He therefore substituted the stave church at Vang, which had recently been dismantled.

Vang stave church had been built in the Middle Ages, and by 1832 was too small and in urgent need of structural repair. The local council had decided to demolish and replace it, and in 1839 JC Dahl intervened to save it. The artist bought the church at a public auction in 1841, and persuaded the then Crown Prince Friedrich Wilhelm of Prussia to pay for the building’s removal, transportation and reconstruction in the remote village of Karpacz Górny in the Giant Mountains in Silesia. It has remained there ever since, serving a Polish Lutheran community, and attracts nearly a quarter of a million visitors each year.

The Norwegian artist Harriet Backer painted interiors of several Norwegian churches, including the stave church at Uvdal. This was built just after 1168, on the remains of an earlier church. It was expanded during the Middle Ages, and again in 1684, 1722 and 1819. Much of its internal decoration was undertaken in 1656, and extended as the building grew. It was taken out of regular use in 1893, and when Backer visited it services took place during the summer. It remains one of the finest decorated churches in northern Europe, and has been lovingly preserved.

Backer’s external view of Uvdal Church and Cemetery from 1906 is a faithful account of what from the outside looks quite a plain building. But once you get inside it, you enter another world.

Backer’s Uvdal Stave Church from 1909 does its rich decoration justice. Her brilliantly coloured view of the interior is lit from windows behind its pulpit, throwing the brightest light on the altar. The walls and ceiling are covered with images and decorations, which she sketches in, manipulating the level of detail to control their distraction. Slightly to the left of centre the main stave is decorated with rich blues, divides the canvas, but affords us the view up to the brightly lit altar. To the left of the stave a woman, dressed in her Sunday finest, sits reading outside the stalls.

The Altar at Uvdal Stave Church, painted the same year, shows the altar from one side, with its painting of the Last Supper hanging above the table, and more decorative work over the walls and ceiling. These have been painstakingly restored in the years since.

Although externally they may appear similar, wooden churches in the Carpathian Mountain region of Ukraine and Poland are structurally distinct, as they don’t rely on staves, but are built from horizontal logs.

At the end of his training in Munich, Teodor Axentowicz paid his first visit to the lands of the Hutsul people, in the Carpathian Mountains of Ukraine. His oil painting of a Hutsul Funeral from 1882 shows the Hutsul in the rigours of winter, the coffin being towed on a sledge behind a cart, and the mourners clutching candles as they make their way through the snow to the wooden tserkva in the distance.

Further reading

Stave church on Wikipedia
Uvdal Stave Church, Wikipedia
Tserkvas of the Carpathians, Wikipedia.

This week’s dive into RunningBoard tackles one of the central questions: this subsystem repeatedly uses the term assertion, but what are these assertions, and how does RunningBoard handle them?

In computing, assertions may have their origin in hardware verification languages like Verilog, where they’re used to state required conditions in declarative form. They appear to have entered macOS through the background service assertiond, which made a name for itself as a killer of processes and apps. Power assertions have been noted in the log and elsewhere for at least the last decade, and are mentioned in IOPMLib, part of IOKit. Since macOS Catalina, assertions have been at the centre of RunningBoard, which remains essentially undocumented.

Developer app

To get a better idea of how assertions are used, I launched Apple’s Developer app on a Mac mini M4 Pro running macOS 15.5, and followed log entries for a period of over 14 seconds from the start of the launch process. Although RunningBoard’s job description records this app’s platform as 6, typical of a Catalyst app, in other log entries it’s claimed not to be a Catalyst app.

At an arbitrary start time of 01.126 seconds, LaunchServices decided to launch this app initially through CoreServicesUIAgent, which 0.04 seconds later requested RunningBoard to execute the launch request. This eventually led to a connection being initialised to FrontBoard Scene Manager, where the app was registered as a new scene, and activated.

Example assertion

FrontBoard set the process visibility to Foreground:
01.593239 com.apple.FrontBoard [app<application.developer.apple.wwdc-Release.9312198.9312203~>:2946] Setting process visibility to: Foreground

RunningBoard then announced it was acquiring a new assertion, giving its descriptor and the PID of the target process
01.593248 com.apple.runningboard Acquiring assertion: <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:(null) target:2946>
01.593288 com.apple.runningboard PERF: Received request from [osservice<com.apple.uikitsystemapp(501)>:748] (euid 501, auid 501) (persona (null)): acquireAssertionWithDescriptor:error:
01.593289 runningboardd acquireAssertionWithDescriptor

A fuller description followed, including the RunningBoard ID, and the attributes of the assertion
01.593324 com.apple.runningboard Acquiring assertion targeting [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] from originator [osservice<com.apple.uikitsystemapp(501)>:748] with description <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:424-748-2228 target:2946 attributes:[
<RBSDomainAttribute| domain:"com.apple.frontboard" name:"AfterLife-Subordinate" sourceEnvironment:"(null)">
]>

This assertion was made active, and RunningBoard stated how many assertions were currently targeting that process
01.593343 com.apple.runningboard Assertion 424-748-2228 (target:[app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946]) will be created as active
01.593389 com.apple.runningboard app<application.developer.apple.wwdc-Release.9312198.9312203(501)> is now targeted by 11 assertions

That triggered a state update for the process
01.593400 runningboardd state update

In this case, RunningBoard couldn’t do anything, so left the process’s assertions as they were
01.593461 com.apple.runningboard _checkForSuspendableAssertionCycle for app<application.developer.apple.wwdc-Release.9312198.9312203(501)> bailing out since it's not holding a suspendable assertion
01.593466 com.apple.runningboard Removing 0 assertions

This did, though, alter the inheritance of existing assertions
01.593556 com.apple.runningboard Process: [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] has changes in inheritances: {(
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2215 0>,
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2215 0>,
<RBSInheritance| environment:(none) name:com.apple.launchservices.userfacing origID:424-391-2214 0>,
<RBSInheritance| environment:(none) name:com.apple.frontboard.visibility origID:424-420-2216 0>
)}

This completed the acquisition of this assertion, and the process’s new state was calculated
01.593564 com.apple.runningboard Finished acquiring assertion 424-748-2228 (target:[app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946])
01.593741 com.apple.runningboard Calculated state for app<application.developer.apple.wwdc-Release.9312198.9312203(501)>: running-active (role: UserInteractiveFocal) (endowments: <private>)

This was all accomplished in around 0.0005 seconds. FrontBoard then continued processing the app’s scene
01.593743 com.apple.FrontBoard Ingesting properties from UIApplicationSceneSettings...

RunningBoard assertion numbers are of the form 424-748-2228, where the second group 748 is the PID of the source of the assertion, and the third group 2228 is a sequential number.

Assertions recorded

• Assertion 424-620-2211 for LaunchServices to launch the app. For this, RunningBoard created its job description with its process ID of 2946, assigned it memory limits, stated the process will be managed, and stated it was running-active with a role of UserInteractive.
• Assertion 424-424-2212 RunningBoard Underlying Assertion. RunningBoard stated the process will be created as active, calculated its processStartTime, created a new RunningBoard Coalition with an ID of 4460, set its Jetsam priority to 0 (the lowest priority over memory use), and set its Darwin GPU to “deny”. Its state was given as running-interactive-NotVisible with a taskState of 4.
• Assertion 424-391-2213 foregroundApp 2946. This changed its role to UserInteractiveNonFocal, and was repeated in assertion 424-391-2214.
• Assertion 424-391-2215 frontmost 2946. RunningBoard changed it to running-active-NotVisible, with a Jetsam priority of 100 (extremely unlikely to be killed to free memory), and Darwin GPU to “allow”.
• Assertion 424-391-2217 LaunchServices notification. It was changed to running-active with a role of UserInteractiveFocal, handshaking took place with the process, and the launch request was recorded. Slightly later, RunningBoard announced it had started “death monitoring” of the process, in case its launch request was denied and the process was killed.
• Assertion 424-748-2218 FrontBoard Bootstrap Background. Following this, the process acquired its first power assertion ID 34241, outside of RunningBoard.
• Assertion 424-2946-2219 Shared Background Assertion
• Assertion 424-655-2220 File Coordination Claim, the first of a series of five similar assertions. For each, RunningBoard recorded Prevent Task Suspend, Prevent Task Throttle Down. After the last it checked for a Suspendable Assertion Cycle, then removed several assertions held for the process.
• Assertion 424-2946-2227 App Nap adapter assertion. RunningBoard then enabled and configured AppNap for the process, and set the AppNap state.
• Assertion 424-748-2228 FrontBoard AfterLife-Subordinate. This is the assertion detailed above.
• Assertion 424-748-2229 FrontBoard Visibility Workspace Foreground Focal. With this, RunningBoard set the process to running-active-Visible with taskState 4.
• Assertion 424-420-2230 App Drawing. Following that, storekitagent was running as PID 2947, accompanying the Developer app.
• Assertion 424-2946-2232 CFNetwork StorageDB.
• Assertion 424-2946-2233 System Animation Fence.
• Assertion 424-420-2234 App Visible. Following that, uikitsystemapp was drawing, presumably for the Developer app.
• Assertion 424-420-2236 FuseBoard Process Window State Visible.
• Assertion 424-2946-2238 system animation fence, which was repeated a total of five times.
• Assertion 424-2946-2244 Shared Background Assertion 1, following which were two more assertions for system animation fence.
• Assertion 424-2946-2247 com.apple.CFNetwork.StorageDB again.
• Assertion 424-655-2248 File coordination claim, repeated in Assertion 424-655-2250.

All these assertions were completed in 14 seconds.

Reading RunningBoard

As shown in the series of assertions recorded in the log for the Developer app, RunningBoard provides a detailed account of milestones through the launch and early running of this app, covering much other than its security and TCC activity.

This starts with a job description containing a great deal of useful information about the app, when it’s neither visible nor focal. At that stage it’s given a minimal Jetsam priority, putting it in the front line to be forcibly quit if memory was short, and it’s denied access to the GPU. As launch proceeds, its Jetsam priority is raised to 100 and it’s allowed GPU access. Its role is then changed to UserInteractiveFocal, its window management is handled by FrontBoard and it becomes visible, and able to undergo AppNap. Two supporting services are engaged, storekitagent to handle its data, and uikitsystemapp to draw its interface.

Once the novelty of RunningBoard had worn off, I had come to consider its incessant chatter in the log as a distraction. However, a log extract obtained with the subsystem set to com.apple.runningboard provides a detailed account of events during an app’s life cycle, without the nuisance of privacy censorship, or the app having to make its own log entries.

Key points for close reading of the log

• Set a predicate for obtaining log entries for the com.apple.runningboard subsystem, and initially filter entries on Acquiring assertion in the Messages field.
• Identify the Process ID of interest.
• Track assertion descriptions, giving the reason for each assertion.
• Note assertion IDs, and interpret them with the aid of the PID given in their second number field.
• Follow assertions for linked processes through their PIDs.

This weekend we’re visiting the rolling chalk Downs in the south of England, including the North and South Downs to the south of London, the Chilterns to the north of the city, and the Berkshire Downs to the west. In the early twentieth century a steady succession of landscape artists moved out from London to live and paint in the hills of southern England.

By 1887, Edward Stott had moved to Amberley at the foot of the South Downs near Arundel in West Sussex, where he lived until his death in 1918. Peaceful Rest is one of his few paintings that was exhibited at the Royal Academy, in this case in 1902. This shepherd has stolen a moment 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 something blue protruding from the shepherd’s jacket pocket. Behind is a shallow chalk cliff at the edge of the Downs.

Stott also painted in pastels. His view of a Chalk Pit near Amberley from 1903 gives a better idea of the rolling chalkland around the village during the harvest, with cut stooks of grain ready for threshing.

At some time in the late summer of 1912, Spencer Gore walked part of The Icknield Way, shown here in his Fauvist view from that year. This is an ancient trackway running from Wiltshire to Norfolk, following the chalk downs of the Berkshire Downs and Chiltern Hills, where he had most probably made sketches of this view of sunset.

Edward Reginald Frampton’s undated view of The South Downs near Eastbourne, East Sussex shows the south-east coast of England during haymaking, with sporadic red poppies in the foreground. The land is otherwise peaceful and deserted, and its sky rises to eternity.

Paul Nash’s autumnal view of the Berkshire Downs was probably painted when he was visiting his father in his home at Iver, in the chalk downland of Berkshire, to the north-west of London.

Nash’s Whiteleaf Cross (1931) might appear unreal, but is quite an accurate depiction of a cruciform hill-carving in Whiteleaf Hill near Princes Risborough in Buckinghamshire, not far from the artist’s family home. On a down set between small woods, a chalk escarpment has been cut with a trench extending to the symbol of a cross above. It is late autumn, with trees devoid of leaves, or their foliage a deep brown.

During the 1930s, Eric Ravilious started spending time in Sussex, where he and his wife became close friends with Peggy Angus, whose house at Beddingham, East Sussex, became their second home. He became particularly fond of painting the chalk downs there, as in his Windmill (1934), where a few barbed-wire fences mark its boundaries.

Around 1939, shortly before the start of the Second World War, Ravilious visited the famous White Horse cut in the chalk downs at Uffington in Berkshire, England. The Vale of the White Horse (c 1939) shows the view from an unconventionally low angle, in pouring rain. This hill figure is thought to date from the late Bronze or early Iron Age, around three millennia ago.

Percy Shakespeare’s painting of December on the Downs, Wartime, made in the period 1939-44, is a lesson in agricultural history. In the distance, on one of the rolling chalk downs in the south of England, are three horse-drawn ploughs tackling some of the steeper ground, while in the foreground are their successors, the light-wheeled modern tractor. Those are being operated here by women, as most of the men were away serving in the armed forces.

For once I end with a couple of my own paintings, admittedly not in the same league as those above. However, they show the downland where I live, and whose escarpments I walk.

This is the Worsley Obelisk on top of the most southerly downs on the Isle of Wight, looking northwards towards the east-west chalk ridge that runs from Culver Down to the Needles, with the city of Southampton in the far distance. The slopes of these hills are scarred by terracettes, once thought to be created by grazing sheep, but now postulated as being a physical effect on soil.

This view looks east across the village we live in, at Saint Martin’s Down, behind which lie Shanklin and Bonchurch, as shown in two of the paintings in the first of these articles. Since painting this ten years ago, much of the rough grazing on this down has been re-wilding and it’s now dotted with small bushes and scrub.

File data integrity is one of those topics that never goes away. Maybe that’s because we’ve all suffered in the past, and can’t face a repeat of that awful feeling when an important document can’t be opened because it’s damaged, or crucial data have gone missing. Before considering what we could do prevent that from happening, we must be clear about how it could occur.

We have an important file, and immediately after it was last changed and saved, a SHA256 digest was made of it and saved to that file as an extended attribute, in the way that you can using Dintch, Fintch or cintch. A few days or weeks later we open the file and discover its contents have changed.

Reasons

What could account for that?

One obvious reason is that the file was intentionally changed and saved without updating its digest. Provided there are good backups, we should be able to step back through them to identify when that change occurred, and decide whether it’s plausible that it was performed intentionally. Although the file’s Modified datestamp should coincide with the change seen in its backups, there’s no way of confirming that change was intentional, or even which app was used to write the changed file (with some exceptions, such as PDF).

Exactly the same observations would also be consistent with the file being unintentionally changed, perhaps as a result of a bug in another app or process that resulted in it writing to the wrong file or storage location. The changed digest can only detect the change in file content, and can’t indicate what was responsible. This is a problem common to file systems that automatically update their own records of file digests, as they are unable to tell whether the change is intentional, simply that there has been a change. This also applies to changes resulting from malicious activity.

The one circumstance in which change in contents, hence in digest, wouldn’t necessarily follow a change in the file’s Modified datestamp is when an error occurs in the storage medium. However, this is also the least likely to be encountered in modern storage media without that error being reported.

Errors occurring during transfer to and from storage are detected by CRC or similar checks made as part of the transfer protocol. This is one of the reasons why a transfer bandwidth of 40 Gb/s cannot realise a data transfer rate of 5 GB/s, because part of that bandwidth is used by the error-checking overhead. Once written to a hard disk or SSD, error-correcting codes are used to verify integrity of the data, and are used to detect bad storage blocks.

Out of interest, I’ve been conducting a long-term experiment with 97 image files totalling 60.8 MB stored in my iCloud Drive since 11 April 2020, over five years ago. At least once a year I download them all and check them using Dintch, and so far I haven’t had a single error.

Datestamps

There are dangers inherent in putting trust in file datestamps as markers of change.

In APFS, each file has four different datestamps stored in its attributes:

• create_time, time of creation of that file,
• mod_time, time that file was last modified,
• change_time, time that the file’s attributes including extended attributes were last modified,
• access_time, time that file was last read.

For example, a file with the following datestamps

• create_time 2025-04-18 19:58:48.707+0100
• mod_time 2025-04-18 20:00:56.134+0100
• change_time 2025-07-19 06:59:10.542+0100
• access_time 2025-07-19 06:52:17.504+0100

was created on 18 April this year, last modified a couple of minutes later, last had its attributes changed on 19 July, but was last read 7 minutes before that modification to its attributes.

These can be read using Precize, or in Terminal, but there’s a catch with access_time. APFS has an optional feature, set by volume, determining whether access_time is changed strictly. If that option is set, then every time a file is accessed, whether it’s modified or not, its access_time is updated. However, this defaults to only updating access_time if its current value is earlier than mod_time. I’m not aware of any current method to determine whether the strict access_time is enabled for any APFS volume, and it isn’t shown in Disk Utility.

mod_time can be changed when there has been no change in the file’s data, for example using the Terminal command touch. Any of the times can be altered directly, although that should be very unusual even in malware.

Although attaching a digest to a file as an extended attribute will update its change_time, there are many other reasons for that being changed, including macOS adding or changing quarantine xattrs, the file’s ‘last used date’, and others.

Proposed strategy

1. Tag folders and files whose data integrity you wish to manage.
2. Back them up using a method that preserves those tags, such as Time Machine, or copied to iCloud Drive.
3. Periodically Check their tags to verify their integrity.
4. As soon as possible after any have been intentionally modified and saved, Retag them to ensure their tags are maintained.
5. In the event that any are found to have changed, and no longer match their tag, trace that change back in their backups.

Unlike automatic integrity-checking built into a file system, this will detect all unexpected changes, regardless of whether they are made through the file system, are intentional or unintentional, are malicious, or result from errors in storage media or transmission. Because only intentionally changed files are retagged, this also minimises the size of backups.

Southern England doesn’t have any mountains or even rugged hills, but rolling Downs. Being uplands you’d have thought they’d be called Ups rather than Downs, but the word has Celtic origins and means a hill fort, as many have been in the distant past. This weekend I invite you to join me on these hills, in the company of some of the artists who have painted them.

Best-known are the North and South Downs, both south of London, while to the north of the capital are the Chilterns, and to the west are the Berkshire Downs. I live in the furthest south of them all, ridges running across the Isle of Wight and dropping into the English Channel.

Under their rich grassland are great whalebacks of chalk, responsible for their roundness and occasional breaks into chalk cliffs. Much of the downland is protected countryside, with scattered woodland and grazing sheep. Although they aren’t high, typically rising to less than 250 metres (800 feet) above sea level, they present short steep ascents for the walker and cyclist, and spectacular views.

It’s only appropriate that my first painting of the North Downs was made by the French artist Théodore Géricault.

In 1820, Géricault accompanied his masterwork The Raft of the Medusa for exhibition in London, and remained in England until the following year. His Epsom Derby painted in 1821 follows the convention of the day in showing galloping racehorses flying through the air without contact with the ground beneath them. The Derby Stakes is a flat race that has been run on Epsom Downs, to the south of London, since 1780. At that time it was run on a Thursday in late May or early June, despite the unseasonal weather seen here.

A few years later the young and aspiring landscape painter Samuel Palmer spent his formative years between 1826-35 living in Shoreham in the Weald of Kent, an area of sandstone hills between the North and South Downs.

From about 1830, Palmer travelled further from the village of Shoreham, and walked up the nearby downs to paint views from the rolling hills looking over the Weald of Kent, such as The Timber Wain (1833-34). Here a team of oxen is being used to draw a heavy wagon bearing a huge tree trunk down to the village in the valley.

His view of The Weald of Kent from about 1833-34 shows another deep valley below and rolling downs beyond.

Palmer’s view of The Golden Valley from about 1833-34 is an open panorama looking over Underriver, near Sevenoaks in Kent, as an oxcart descends into the valley from the ridge.

In the 1850s, Palmer returned to the rolling downs of the Kent countryside, where he painted this delicate view from Wilmot’s Hill, Kent (c 1851), which makes interesting comparison with his paintings from his time at Shoreham. This is in the chalkland of the North Downs.

During the middle of the nineteenth century a few artists visited the Isle of Wight to paint its chalk downs.

Richard Burchett’s View Across Sandown Bay, Isle of Wight was painted from the path that still runs to the west of Saint John’s Church (now known as Saint Blasius’), Shanklin, towards Cliff Copse, in the south of the island. The distant chalk cliffs are the end of Culver Down, at the eastern end of the ridge that runs to West High Down and the Needles in the extreme west.

At Ventnor, Isle of Wight (1856) is a superb watercolour painted by Barbara Bodichon on the coast just a few miles to the south-west of Burchett’s viewpoint. It conforms to the Pre-Raphaelite expectations of landscape painting, and captures the spirit and detail of the chalk cliffs along this stretch of the Channel coast. Painted from near Saint Catherine’s Point, in a friend’s studio, looking east into the dawn sky, it was successfully exhibited at the Royal Academy.

The following year John Brett, the leading Pre-Raphaelite landscape artist, started work on The Stonebreaker (1857-58), at a popular beauty spot in the North Downs, near Box Hill (elevation 224 metres, 735 feet), which dominates the distance. The milestone at the left shows the distance to London as 23 miles, and David Cordingly considers this places it along a historic track known as Druid’s Walk, leading from the Pilgrim’s Way over the Leatherhead Downs to Epsom and London.

Brett made extensive sketches and studies of the motif, worked on the final oil painting for at least twenty days en plein air, but then completed it in the studio during the following autumn and winter. The painting was shown at the Royal Academy in 1858, where it aroused considerable critical interest.

During the winter of 1865-66, Brett’s patron stayed on or near the Isle of Wight, where Brett painted two watercolour landscapes of the Island, of which only February in the Isle of Wight (1866) has been traced. This is where the chalk downs reach the English Channel, probably near Bonchurch in the far south of the island. If that’s correct, the sailing ship in the distance is at the southern end of Sandown Bay, opposite Culver Cliff. This area has suffered major landslips, in 1810, 1818, 1995, and most recently in December 2023.

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

1: Total banker’s order quickly verifies integrity.

2: 1 broke by 2005, 2 is still cryptographic, 3 is even better, but not in Iran.

3: Missing from …MNOPQTUVW… but present in CD.

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.

Plenty of great apps have been created using the Mac’s scripting languages, but commercial developers have largely relied on compiled languages used and supported by Apple for app and system development. Over the years those have included Object Pascal, C/C++, Objective-C and most recently Swift. This article provides a brief overview of how those changed.

Lisa Clascal (1984-86)

Following Apple’s use of UCSD Pascal on Apple II computers, when the Lisa was being developed its primary language was Lisa Pascal. Apple was also working on the novel object-oriented language Smalltalk which originated in Xerox’s PARC in 1969, but its syntax was unfamiliar and performance was poor. Lisa Pascal was therefore developed into Clascal, dividing code into distinct interface and implementation sections, with classes, subclasses, methods and inheritance.

During the first couple of years, software for the Mac was thus developed using Clascal on Lisa systems.

Object Pascal (1986-91)

In 1984-85, Larry Tesler and supporting engineers in Apple (including Barry Haynes, Ken Doyle and Larry Rosenstein) worked with Niklaus Wirth, the inventor of Pascal, to develop Clascal into Object Pascal, the primary language for Mac development. With this, they also developed the first version of the MacApp class library that provided a framework to support common application features including the Mac’s GUI.

These were released together in September 1986, in Macintosh Programmer’s Workshop (MPW), which was adopted as the standard development environment for the Mac, both in-house and for third-parties. At that time, the only compiled language supported by MPW was Object Pascal, and it wasn’t until the following summer that the first beta of its C/C++ compiler was released with MPW 2.0. That was developed by Greenhills, but Object Pascal remained the more widely used, particularly in combination with MacApp, also written in Object Pascal. Major developers including Adobe created early versions of their products using Object Pascal and MacApp, perhaps the most famous example being Adobe Photoshop.

At the same time, Think Technologies released the first popular third-party compiler, LightSpeed C, in 1986. This soon became THINK C, gained C++ support, was joined by THINK Pascal, and was bought by Symantec. Borland ported its Turbo Pascal to the Mac, where it adopted the extensions of Object Pascal, and eventually became the cross-platform Delphi in 1995.

C/C++ (1991-2001)

With the release of System 7 in 1991, Apple abruptly switched from Object Pascal to C++, and MacApp 3.0 also changed language. Smaller developers who had extensive source in Object Pascal were far from happy, and in some cases successful products vanished from the market. Others were rescued when Metrowerks released a new integrated development environment for C/C++ as CodeWarrior at the end of 1993 or early 1994. This drew most who had been using THINK C, and MPW also went into decline. The decisive factor was CodeWarrior’s early support for Apple’s new PowerPC Macs. CodeWarrior’s C/C++ saw many Mac developers through that hardware transition until the release of Mac OS X in 2000-01.

Objective-C (2001-)

With Mac OS X came its own primary development language Objective-C, and Apple’s new integrated development environment Project Builder, also derived from NeXTSTEP but written from scratch for the Mac. That was replaced by the first version of Xcode with Mac OS X 10.3 Panther in 2003.

This screenshot shows Xcode in 2015.

Objective-C had been one of the two object-oriented contenders to succeed C. The other, C++, had already become more widely adopted, and had been favoured by Apple for the previous decade. Although both claim C as their ancestor, there’s little in common between them, and in many respects Objective-C more closely resembles Smalltalk, rejected by Apple when developing the Lisa. Developers whose source code had started in Object Pascal and was then ported to C++, had another major task to convert that to Objective-C.

Originally designed and developed by Brad Cox and Tom Love during the early 1980s, Objective-C’s biggest success had been its selection as the primary development language for NeXTSTEP later that decade. When Apple adopted that as the foundation for Mac OS X, it was inevitable that the language should come with it.

Swift (2014-)

In keeping with its track record, no sooner had Apple entered the 2010s than its engineers, under the lead of Chris Lattner, were working on the successor to Objective-C. Significant early collaborators included Doug Gregor, John McCall, Ted Kremenek and Joe Groff. A first beta-release was provided at WWDC in 2014, and since then Swift has been progressively replacing Objective-C as Apple’s primary development language.

Swift is described as being a multi-paradigm language, and over the course of the last 15 years it has assimilated and adopted almost every available programming paradigm, from classes and objects to protocols and declaratives. Although it’s still possible to write plain code that is understandable by someone with a grounding in C or Pascal, those who prefer to adopt almost any other paradigm can render their code nearly unintelligible to others. Differences between the current version 6.1.2 and version 1.0 from 2014 are huge.

From those early days, Swift has had an interactive mode, based on the ‘read-eval-print loop’ (REPL) popularised by Lisp. This versatility has been developed in Swift Playgrounds, both within Xcode and as a standalone app targeted at those of all ages learning to code for the first time.

As an introduction to Swift in education, this has been impressive, but it hasn’t proved a gateway for those who didn’t really want to learn how to use Xcode in the first place.

With the release of Swift 5.0 in February-March 2019, the language reached a major milestone of stability in its application binary interface (ABI). Prior to that, executable code built from Swift source had to be delivered with its own copy of Swift’s runtime libraries, amounting to over 11 MB for regular apps. Starting from the release of macOS 10.14.4, and Xcode 10.2, apps written in Swift 5.0 didn’t need those frameworks (except for compatibility when running on older macOS), as their ‘glue’ to macOS has since been delivered in the system. Later that year, module stability was added, to allow sharing of binary frameworks compatible with future versions of Swift.

This screenshot shows the Interface Builder feature in Xcode in 2024.

Others

Although those have been primary development languages, Apple and third-parties have supported many others. Here’s a small personal sample.

In 1984, what was to become Macintosh Common Lisp (MCL) began development. It was released in 1987, initially as Coral Common Lisp (CCL), then Macintosh Allegro Common Lisp, and MCL. It moved on to Digitool in 1994 for PowerPC support, and was made open source in 2007. Unusually for what’s normally considered a specialist language, MCL was well integrated with Mac OS and its GUI.

After MCL drifted off into oblivion, LispWorks’ cross-platform implementation of ANSI Common Lisp took over, and remains thoroughly mature and productive, with extensive browsing facilities, debugging, and more.

An extraordinarily concise and powerful language, APL is also one of the oldest, having been defined in 1962 and first implemented a couple of years later. It uses Greek and special symbols in its own custom font, concatenating them into cryptic lines that make perl look verbose. Its last Mac implementation, MicroAPL’s APLX 5.1, was still able to run in El Capitan, but has sadly been abandoned. However, Dyalog APL remains actively developed, and even supports Apple silicon Macs. Other notable losses include Absoft, whose Fortran compilers were widely used on Macs from 1985, and shut down in 2022.

Microsoft’s Visual Studio Code, supporting more than thirty programming languages including JavaScript, C#, C++, and Java, was a latecomer to the Mac, and has most recently become VS Code.

References

David Cásseres (1983) Clascal Reference Manual for the LISA, First Draft
Clascal, Wikipedia
Larry Tesler (1985) Object Pascal, Report
Object Pacal, Wikipedia
MPW, Wikipedia
CodeWarrior, Wikipedia
Swift, Wikipedia

The overwhelming majority of paintings of interiors show rooms we might aspire to. In this last of the series, I show some we’d all hope to avoid, those of the poor and destitute. Although never really popular as motifs, there have always been a few artists prepared to tackle the ills and inequalities in society, and this became increasingly frequent in the 1880s.

In common with other paintings of inns in the Dutch Golden Age, David Teniers the Younger’s The Dice Shooters (1630-50) is set in a dingy room in a rough tavern. Drawing on their clay pipes and with glasses of beer in hand, a group of men appear completely absorbed in gambling their large stacks of coins on the throw of their dice.

Bartolomé Esteban Murillo is one of the earliest artists to have paid particular attention to the poor. The Young Beggar, painted in about 1645, shows a young boy squatting in a tiny bare nook in a building. By his filthy feet is a bag full of rotting fruit, and some sort of worms, which apparently form his diet.

François-Auguste Biard’s undated sketchy view In a Mountain Hut may have been made in front of the motif, onto paper. This is unusually social realist for this artist, showing the abject poverty and spartan conditions of many who lived in the more remote areas of France at that time.

It was the Naturalist paintings of Jules Bastien-Lepage in the early 1880s that brought depictions of the poor to success in the Salon.

Typical of his portraits is The Little Chimneysweep (Damvillers), one of his last paintings, completed in 1883. This young chimneysweep sitting in his tiny hovel with a stray cat and kitten has the air of authenticity. The hand grasping that slab of bread is still black with soot. Bastien painted this in his home village in northern France.

Antonino Gandolfo’s Compensation (1880-85) depicts prostitution in the city of Catania on the east coast of the island of Sicily, Italy. The man settling his bill is only seen by his hand holding out money, and a foot. The young woman holding out her hand to receive looks away in shame, and wears scarlet to advertise her trade.

We remain in the poor quarter of Catania for Gandolfo’s The Last Coin (c 1880-85). A young woman, who has been spinning, sits on an old chest and takes the last money from her purse, presumably to pay for some milk to fill her blue and white jug. Her family stand with their heads bowed in the gloom behind.

Vincent van Gogh’s early paintings of Nuenen, such as The Potato Eaters from April 1885, depict poor peasant families, here eating inside their dingy cottage lit by a single oil lamp.

Arturo Michelena’s Charity from 1888 shows a pair of charitable bourgeois ladies arriving at the hovel that is home to a young mother and her small child. Beside the woman, on a small table under the window, are a couple of bottles of her favourite ‘poison’, quite likely absinthe.

For the last nine years, Apple silicon chips in iPhones and iPads, and most recently Macs since 2020, have had Efficiency cores, designed to eke out their use of power to extend battery time and stay cool. Although you have no control over what runs on the Efficiency cores in a device, there are options for Macs. This article explains how you can reduce energy use in an Apple silicon Mac, and why that’s a good idea.

M series chips can have between 2 and 8 E cores, each with slightly less than half the processing power of their Performance core equivalent. If you’re unsure how many CPU cores of each type your Mac has, and how they’re used, open the CPU History window in Activity Monitor and watch.

Particularly in the first few minutes after starting a Mac up, the E cores will be busy catching up with their housework, routine tasks such as updating Spotlight’s indexes, checking for various updates, and making an initial backup. Once those are out of the way, you’ll see other bursts of activity, such as XProtect Remediator scans, and a steady trickle of background tasks. Because most user processes are run on the P cores, even hectic E core activity has no effect on what you’re doing.

When threads run on the E cores, they run more slowly, take longer to complete, and for all that take substantially less energy and power. That’s because those cores are designed to be more energy-efficient and are run at lower frequencies, or clock speeds. For almost any given task, running its threads on E cores will thus use less total energy, and

• run a laptop Mac’s battery down less,
• generate less heat, so keep the Mac cooler,
• leave the P cores free for more pressing work.

In-app controls

Although the code run by apps can’t be directly allocated to P or E cores, macOS can get a strong hint by a setting known as the Quality of Service (QoS). By default, the whole of a user app will normally be run at high QoS, and macOS will try to do that on P cores, so long as they’re available.

Some apps are starting to give the user control over this in a ‘speed control’. Among those is the compression utility Keka.

In Keka’s settings, you can give its tasks a maximum number of threads, and even run them at custom Quality of Service (QoS) if you want them to be run in the background on E cores, and not interrupt your work on P cores. Although you’re unlikely to do this when compressing or decompressing a few small files, when its tasks are likely to take several minutes, and you can afford to wait a little longer, run them on the E cores.

Two of my apps, Dintch and Cormorant, have even simpler controls.

Dintch has a three-position slider, offering

• a red racing car for top priority on P cores when possible;
• a blue truck for medium priority on P cores when possible;
• a green tortoise for the E cores.

The first two of those took 6.2 seconds to check a 16.8 GB file, and the third took almost 25 seconds. The difference between the first two is in their priority, if there are several threads competing for the same CPU cores. If you’re waiting for files to be checked in Dintch, set the speed control at the racing car, but if you can leave the Mac to get on with checking in the background and want the efficiency of E cores, set the control to the tortoise instead.

Cormorant, a much simpler compression utility aimed at AirDrop transfers, has a fourth slider position with a pointing hand that allows you to set a custom number of threads and QoS level, as I also use that to test and compare P and E cores.

Activity Monitor

You can observe the effects of these controls in Activity Monitor’s CPU History window.

Here’s the window after Dintch has checked that 16.8 GB file with the setting for the racing car. All the P cores show four bursts of activity as they run the code to compute the SHA256 digest.

When set to the tortoise, there’s almost no activity on the P cores, but the four E cores are busy computing for nearly 25 seconds.

One word of caution about over-interpreting what you see in the CPU History window. Both P and E cores can run at a wide range of frequencies, but Activity Monitor takes no account of that. Taken at face value, you might think these E cores were working far harder than the P cores, but in fact they were only running at low frequency, little more than idle. In contrast, those small bursts of P core activity were at higher frequency, so were using far greater energy and power, albeit more briefly.

Other apps

I’m sure that other apps are offering the user control over whether their longer tasks are run on the E cores, and will be pleased to learn of them. There are also two ways that you can control them yourself, using St. Clair Software’s excellent utility App Tamer, or the command tool taskpolicy.

App Tamer works best with apps, and makes it simple to demote their threads so they’re run on E cores in the background. If you want to demote the threads of a running process from Terminal, use a command like
taskpolicy -b -p 567
to confine all threads of the process with PID 567 to the E cluster. You can then reverse that using the -B option for threads with higher QoS, but can’t alter those set to a low QoS by the process. The ground rule here is that high QoS threads can be demoted to the E cores, but low QoS threads can’t be promoted to run on the P cores.

What to avoid

Running a virtual machine on an Apple silicon Mac always uses P cores first, even though they will also be used to run background threads inside the VM. So the worst thing you can do in terms of energy efficiency and core use is to run code inside a VM.

Summary

• Run task threads on E cores for better battery endurance, lower heat production, and to keep other apps more responsive.
• Where an app provides a control, use it to run long tasks in the background, on the E cores.
• For apps that don’t, use App Tamer. For processes use the taskpolicy command tool.
• Avoid running a VM if you want high efficiency.

A century ago today, on 17 July 1925, the great German artist Lovis Corinth died. To complete this series commemorating his career and art, I show a selection of the best of his narrative paintings. Some modern art historians claim that narrative painting died during the nineteenth century, but that certainly didn’t apply to Corinth.

Corinth’s first really successful narrative paintings were the two that he made in 1890, showing the Old Testament story of Susanna and the Elders, a subject he returned to as late as 1923. Identical in their composition, they have an unusual setting, as this scene of the two elders acting as voyeurs is more commonly shown in Susanna’s garden, or even woodland, as described in the original story.

Towards the end of his time in Munich, Corinth painted this first version of another famous story, this time the temptations that Saint Anthony was reported to have undergone. This is more typical of Corinth’s mature work, with many figures crammed into the composition in a raucous and highly expressive human circus. Although painterly in parts, he is careful to depict fine detail in the joint of meat being held by Saint Anthony, and the saint’s amazing face.

Corinth’s narrative paintings reached their peak at the time that he moved to Berlin, in this second version of Salome. Not only was it highly influential on a wide range of other artists and their arts, but its use of gaze is remarkably subtle and its success based on being implicit rather than explicit.

Corinth wasn’t as restrained when he tackled the story from Homer’s Odyssey of Ulysses Fighting the Beggar. He packs a crowd in, gives every one of them a unique and intriguing facial expression, then pits Ulysses against the beggar in almost comic combat. Note too how his figures are becoming looser.

If Corinth’s first Temptation of Saint Anthony showed a human circus, the rest of the animals and performers came for this his second. Those figures are also becoming significantly more painterly, and the Queen of Sheba has similarities with his earlier figure of Salome.

Of all his narrative paintings, his Homeric Laughter must be the most complex. It refers to a story within the story of Homer’s Odyssey, told by the bard Demodocus to cheer Odysseus up when he is being entertained by King Alcinous on the island of the Phaeacians. It’s another raucous spectacle, in which we join the other gods in seeing Mars and Venus caught red-faced making love.

Corinth returned to narrative after his stroke, painting The Blinded Samson with its obvious autobiographical references. Samson’s body is painted more roughly, although the artist has taken care to give form to the drops of blood running down Samson’s cheeks. This version of Samson contrasts with his others in showing the man alone.

Less than two years after his stroke, Corinth returned with another elaborate and wild painting, this time depicting the story of Ariadne on Naxos. This is another highlight of Corinth’s career, particularly as it condenses several different moments in time into its single image, using multiplex narrative; that might have been fairly commonplace during the Renaissance, but was exceptional for the early twentieth century. It works wonderfully.

Late during the First World War, Corinth moved on from crowded and vivacious narrative paintings, and became more autobiographical again. The huge and stark figure of Cain heaping rocks onto the body of his brother Abel fits with Corinth’s growing horror and despair as the war drew on.

Corinth’s last painting of Susanna and the Elders is a remarkable contrast with his first, from over thirty years earlier. He still avoids a pastoral or garden setting, and his figures are now fading forms in patches of colour and texture.

For what must have been his last great narrative painting, Corinth looked to the events leading up to the fall of Troy, in particular The Trojan Horse. The great walls and towers of the city appear as a mirage, their forms indistinct from the dawn sky. Although roughly painted using coarse marks, the soldiers and the horse itself are more distinct in the foreground.

Corinth’s style evolved through his career, but he also continued to paint stories right up to the last. Together, they form one of the most sustained and brilliant series of narrative paintings of any artist since Rembrandt.

References

Wikipedia.

Lemoine S et al. (2008) Lovis Corinth, Musée d’Orsay & RMN. ISBN 978 2 711 85400 4. (In French.)

It’s commonly claimed that software encryption, as used in APFS Encrypted format, incurs negligible overhead. The last time I looked at that was with Thunderbolt 3 SSDs connected to a Mac Studio M1 Max, when I found that varied according to the SSD. One of the three I tested then did show significant reductions in encrypted write speed, from 2.2 to 1.8 GB/s, but the fastest showed no change from its unencrypted write speed of 2.8 GB/s. This article reports new test results from a Mac mini M4 Pro with faster SSDs, one Thunderbolt 5 and the other USB4, and adds data for computing SHA256 hashes.

These are of particular interest, as not only are the unencrypted transfer speeds for both SSDs significantly higher than Thunderbolt 3, but the host has significantly faster CPU cores.

Two sets of measurements were made on each of the two SSDs:

• Stibium 1.2 running on macOS 15.5 Sequoia was used to measure read and write speeds over randomised sequences of a total of 53 GB in 160 files of 2 MB to 2 GB individual size.
• Stibium was used to measure the single file read speed of a 16.8 GB IPSW file, and Dintch was used to measure the time taken to stream the file in and compute its SHA256 digest, using CryptoKit.

Read and write speeds

Results of the first series of tests showed both SSDs performed as expected when using plain APFS, with read and write speeds of 5.3 GB/s for TB5, and 3.7 GB/s for USB4.

Small reductions in read speed were seen in both SSDs when using APFS Encrypted, to about 98% and 95% of their unencrypted read speed. Although there was a similar small reduction in write speed for USB4, to 97%, that seen in the Thunderbolt 5 SSD was greater, with a fall from 5.3 to 4.7 GB/s (89%). Both sets of tests were repeated for that SSD, allowing ample time for the SLC cache to be emptied after each set of write tests, and results remained essentially the same.

Although write speed to APFS Encrypted for this Thunderbolt 5 SSD remained well above that for USB4, encryption brought a reduction in speed of just over 10%, more than I had anticipated.

Hash computation

SHA256 and SHA512 digests are now used to check file data integrity. Both are computationally intensive, and I have previously reported that reading files of substantial size and computing their digests using CryptoKit proceeds at about 3 GB/s for files stored on the fast internal SSD of a Mac mini M4 Pro.

With the Thunderbolt 5 SSD, a plain file of 16.8 GB was read at 6.5 GB/s, and encrypted at 4.7 GB/s. SHA256 digest computation was performed at 2.6 GB/s from plain APFS, and 2.2 GB/s from APFS Encrypted, both well below that from the internal SSD, and less than half the speed of just reading the file.

Although the USB4 SSD was inevitably slower on the read tests, at 3.8 GB/s, encryption had little effect, at 3.7 GB/s. SHA256 digest computation was, if anything, faster than with Thunderbolt 5, at 2.8 GB/s plain, and 2.7 GB/s encrypted.

Conclusions

Although there may well be differences with other Thunderbolt 5 and USB4 SSDs, and more extensive results would be helpful:

• Whether plain or encrypted APFS, Thunderbolt 5 SSDs are substantially faster than USB4.
• Encryption can result in significantly lower write speeds on some Thunderbolt 5 SSDs.
• Otherwise, encryption has only small effects on read and write speeds.
• Computation of SHA256 digests is significantly slower than encryption, and ranges between 2.2-2.8 GB/s on larger files.
• This suggests that, even in faster M4 chips, CPU performance limits the speed of software encryption, and even more so for SHA256 digest computation.

This second article concludes my virtual exhibition of a selection of Peter Paul Rubens’ paintings of myths from Ovid’s Metamorphoses.

Rubens and his workshop painted several different accounts of Ovid’s great story of the Calydonian Boar Hunt. This is the first, from about 1611-12, with Meleager just about to finish the wounded boar off. Atalanta’s arrow is visible by its left ear, and the body of Ancaeus lies just behind Meleager’s left foot. The wall of horses behind the boar, and the crowd of hunters behind Meleager, including Atalanta in blue, frame the combatants in the foreground, with some spears directing the gaze at a visual centre of the boar’s snout.

A few years later, in about 1618-19, Rubens reworked his composition in this marvellous study of Meleager and Atalanta and the Hunt of the Calydonian Boar. This shifts the visual centre closer to the geometric centre, and brings the gaze in using a greater range of radials. It also gives Atalanta a more active part, as in Ovid’s text.

Rubens’ finished result is The Hunt of Meleager and Atalanta probably from around 1618-20. Meleager has aged slightly, and the boar rests its hoof on the body of Ancaeus. Radial lines of spears are augmented by a dog and some human figures, and the centre of the painting now includes a landscape, with bright sky used to emphasise the visual centre. It also seems to show not just Atalanta at the right hand of Meleager, but two other women behind her, and possibly another in blue robes on a horse just above the middle of the painting.

Rubens and his workshop’s Meleager Presents Atalanta with the Head of the Calydonian Boar (before 1640) shows the award of the trophy by Meleager. The couple are here alone, apart from an inevitable winged cupid, and a goddess, most probably Diana, watching from the heavens. Meleager stands on the forelegs of the dead boar, and his spear behind is still covered in its blood.

Around 1615, Rubens collaborated with Jan Brueghel the Elder (father of Jan Brueghel the Younger) in The Feast of Achelous. There are nine men around the banqueting table, without any distant nymphs.

His Stormy Landscape with Philemon and Baucis from about 1625 is one of the few paintings to show a broader view of this late moment in Ovid’s story. His dramatic landscape shows storm-clouds building over the hills, a raging torrent pouring down the mountainside, dragging large trees and animals in its swollen waters, and the four figures on a track at the right. Philemon and Baucis are struggling up the track with their sticks, Jupiter points to a rainbow formed over a waterfall at the lower left corner, and Mercury is all but naked.

Rubens and Jan Brueghel the Elder also collaborated in Nymphs Filling the Horn of Plenty, again in about 1615. Although it has no references to the fight between Hercules and Achelous, it’s good to see the staff preparing the second course of Achelous’ banquet.

This marvellous painting was probably made by Rubens’ workshop around the time of the Master’s death in 1640. It views The Abduction of Deianeira by the Centaur Nessus from the bank on which Hercules is poised to shoot his arrow into Nessus. This has the centaur running across the width of the canvas, his face and body well exposed for Hercules’ arrow to enter his chest. To make clear Nessus’ intentions, a winged Cupid has been added, and Deianeira’s facial expression is clear in intent. An additional couple, in the right foreground, might be intended to be a ferryman and his friend, who appear superfluous apart from their role in achieving compositional balance.

A few years before his death, Rubens painted a wonderful account of The Birth of the Milky Way (1636-37). Jupiter sits in the background on the left, seemingly bored. Juno’s milk arcs out from her left breast over the heavens, and her peacocks look distressed.

His atmospheric painting of the flight of Orpheus and Eurydice (1636-38) was also made during his later years of retirement, a few years before his death. Orpheus, clutching his lyre, is leading Eurydice away from Hades and Persephone, as they start their journey back to life. He opts for an unusually real-world version of Cerberus at the bottom right corner.

Rubens’ The Rape of Ganymede (1636-37) is surprising for its use of profane humour, with the placement of both ends of Ganymede’s quiver. Clearly this wasn’t intended for viewing by polite mixed company.

In 1636, when he was in retirement, Rubens made one of his wonderful oil sketches of The Death of Hyacinth, capturing the scene vividly, as Hyacinthus’ head rests against the fateful discus. This doesn’t seem to have been turned into a finished painting.

Rubens skilfully reversed Titian’s composition in his undated Venus and Adonis. Adonis is trying to depart to the left with his back to the viewer, bringing the beauty of Venus into full view, and strengthening its triangular composition. It also provides a natural place for Cupid, holding onto Adonis’s leg to stop him from going to his death. Cupid’s quiver, left on the ground behind him, is a reminder of the origin of the relationship.

In or just before 1614, Rubens made this oil sketch of Venus Mourning Adonis, a complex composition with the addition of three Graces, and the young Cupid at the right.

Rubens’ finished version of Death of Adonis retains the same composition. A rather portly Venus cradles her lover’s head as the Graces weep in grief with her. Rubens has been generous with the young man’s blood, which is splashed around his crotch and spills out onto the ground, where the hounds are sniffing it. The fateful spear rests under Adonis’s legs.

His painting of The Rape of Hippodame (Lapiths and Centaurs) (1636-38), remains faithful to his earlier sketch and its composition. Facial expressions, particularly that of the Lapith at the left bearing a sword, are particularly powerful.

Rubens’ The Death of Achilles (c 1630-35) also adheres faithfully to an earlier oil sketch. Achilles’ face is deathly white, and this brings to life the supporting detail, particularly the lioness attacking a horse at the lower edge of the canvas, symbolising Paris’s attack on Achilles.

Rubens included this oil sketch in his Achilles series, showing Thetis Dipping the Infant Achilles into the River Styx (1630-35). This is taking place in the foreground, while in the middle distance Charon is seen ferrying the dead across the River Styx into the Underworld.

In his late oil sketch of Vertumnus and Pomona of 1636, there’s no pretence that Vertumnus is a woman: he lacks breasts, and even has heavy beard stubble. However, the embrace of his right arm still brings Pomona to push him away with her left arm.

The outstanding depiction of Ovid’s story is Rubens’ earlier Vertumnus and Pomona from 1617-19. Vertumnus has assumed his real form, that of a handsome young man. Pomona looks back, her sickle still in her right hand, and her rejection of his advances is melting away in front of our eyes. Rubens even offers us a couple of rudely symbolic melons, and provides distant hints at Vertumnus doing the work in the garden while Pomona directs him, at the upper left.

In about 1618-20, Rubens collaborated with Frans Snyders to paint Pythagoras Advocating Vegetarianism. The mathematician and philosopher sits to the left of centre, with a group of followers further to the left. The painting is dominated by its extensive display of fruit and vegetables, which is being augmented by three nymphs and two satyrs. One of the latter seems less interested in the food than he is in one of the nymphs.

How can you check whether important data has acquired errors? It could be in packets transferred over a network, files being stored in the cloud, or those put in an archive for safe-keeping. This article explains how errors can be detected and in some cases corrected.

Checksum

One quick and simple way to keep track of whether errors have crept in is to add all the byte values together using modulo arithmetic, and see if that number matches what we expect. Modulo addition ensures the sum never exceeds 255 (for 8-bit bytes), but it also means there’s a 1 in 255 chance that the checksum may remain correct even when the data is wrong. There’s an even more serious problem, though, as changing the order of bytes in the data won’t have any effect on their checksum, even though it would scramble the data.

One solution to those is the Fletcher checksum, using two values instead of one. Both start at zero, then the value of the first block of data is added to the first of those. That is then added to the second value, and each time another value is added to the first, their total is added to the second value. At the end the two values are combined to give the Fletcher checksum.

As this only uses modulo addition, it’s extremely quick, so is used with 32-bit blocks for the Fletcher-64 checksum in APFS file system metadata. The chances of a ‘collision’, in which an error fails to show up in the checksum, are almost 1 in 4.3 billion. Wikipedia’s account includes worked examples.

Cyclic redundancy check

These use additional bits to form cyclic codes based on the remainder of a polynomial division of the data contents. Although they sound complex, they use simple binary operations, so can be very quick in use. Again, Wikipedia’s account includes worked examples.

These were originally developed for use over communication channels such as radio, where they are effective against short bursts of errors. Since then they have been widely used in hard disks and optical storage. They have two main disadvantages, in that they can easily be reversed, allowing the original data to be reconstructed, and they can’t protect against intentional modifications.

Hash

Secure Hash Algorithms, SHA, are a family of cryptographic functions based on a one-way compression function. The first, SHA-1, produces a 160-bit value referred to as the digest. Used from 1995, it was broken in 2005, and has been replaced by SHA-2 using digest sizes of 224-512 bits, now most widely used as SHA-256.

For SHA-256, data is processed in 512-bit chunks and subjected to 64 rounds of a compression function before being appended into the 256-bit digest, while SHA-512 uses 1024-bit chunks and 80 rounds. Full details are again given in Wikipedia.

Important properties of cryptographic hash functions include:

• There’s a one-to-one mapping between input data and hash, so the same data always generates the same hash.
• It’s not feasible to work out the input data for any given hash, making the mapping one-way.
• Collisions are so rare as to not occur in practice.
• Small changes in the input data result in large changes in the hash, so amplifying any differences.
• Hash values should be fairly evenly distributed.

SHA-256 and related hashes are used in code signatures, as CDHashes of the protected parts of each app, bundle, etc. They’re also used to verify the integrity of the Signed System Volume in modern macOS, where they’re assembled into a tree hierarchy so they can be verified lazily, on-demand. More generally, cryptographic hashes are used in message authentication codes (MAC) to verify data integrity in TLS (formerly SSL).

Error-correcting code

Those methods of detecting errors can’t, in general, be used to correct them. The first effective error-correcting code was devised by Richard Hamming, and is named after him. It can correct all single-bit errors, and will detect two-bit errors as well. Wikipedia’s excellent account, complete with explanatory Venn diagrams, is here.

Ten years after Hamming code came Reed-Solomon code (R-S), invented by Irving S Reed and Gustave Solomon. Nearly twenty years later, when Philips Labs were developing the format for CDs, their code was adopted to correct errors in their reading. Unlike others, when used in CDs, R-S codes are applied to bytes rather than bits, in two steps.

The first encodes 24 B of input data into 28 B of code. Interleaving is then performed on those codewords in blocks of 28, or 784 B of codewords, following which a second R-S coding is performed to convert each 28 B into 32 B of code. The overall code rate is thus 24/32, so an input file grows by a third following this double encoding. R-S code is explained in detail in this Wikipedia article.

The reason for such a complex scheme of error-correction in CDs is to correct bursts of errors up to 4 KB, or 500 bytes, representing about 2.5 mm of the track on a CD. Similar methods have been used for DVDs and in parchive files, which were distributed in USENET posts. However, it becomes progressively harder and less efficient to provide error-correction for larger blocks of missing data, which is of course one of the most serious problems in computer storage systems.

macOS

Unlike some file systems including Zfs, APFS and macOS don’t provide any native method for checking the integrity of data stored in files, although macOS does offer SHA-256 and SHA-512 support in CryptoKit. My free suite of two apps (Dintch and Fintch) and a command tool (cintch) offer a robust scheme using CryptoKit’s SHA-256 that I and others have been using for the last five years. Details are in their Product Page.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5305. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new rule for MACOS.SOMA.JLEN, part of the Amos/Soma family of malware.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5305

Sequoia systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5305 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Several Masters have specialised in painting myths told in Ovid’s Metamorphoses. Although Nicolas Poussin painted many, perhaps the most prolific is Peter Paul Rubens, whose work has featured in nearly half the articles in this series. Here, possibly for the first time, I bring together a virtual exhibition of some of his best narrative paintings drawn from Ovid.

Rubens’ Deucalion and Pyrrha (1636) shows an aged couple, clearly beyond any hope of parenthood, which at least explains why this metamorphosis was needed. As their more reasonably sized rocks transform, they follow an ontogenetic process, instead of behaving like sculpted blocks. Rubens also treats us to some interesting details: the couple’s boat is shown at the top right, and a newly transformed couple appear already to be engaged in the initial stages of making the next generation without the aid of metamorphosis.

His late oil sketch of Pan and Syrinx from about 1636 is one of the few paintings that attempts to show Syrinx undergoing her transformation into reeds, and succeeds in making Pan appear thoroughly lecherous.

Rubens’ finest painting of the story of the rape of Io is his Juno and Argus from about 1611, showing this part of its outcome. Juno, wearing the red dress and coronet, is receiving eyes that have been removed from Argus’ severed head, and is placing them on the tail feathers of her peacocks. The headless corpse of Argus lies contorted in the foreground. Rubens took the opportunity of adding a visual joke, in which Juno’s left hand appears to be cupped under the breasts of the woman behind.

His The Fall of Phaeton, started in about 1604, is perhaps the best of several superb paintings of this story. He seems to have reworked this over the following three or four years, and elaborates the scene to augment the chaos: accompanying Phaëthon in the chariot of the sun are the Hours (Horae, some shown with butterfly wings), who are thrown into turmoil, and time falls out of joint as Phaëthon tumbles out of the chariot.

His is also one of the best accounts of Jupiter and Callisto (1613). Diana looks a tad more masculine than in most depictions, and their facial expressions are more serious, with Callisto hesitant and suspicious. Most importantly, Rubens tells us that this Diana is more than meets the eye: parked in the background is Jupiter’s signature eagle, with a thunderbolt in its talons.

This is the better of his two versions of Erichthonius Discovered by the Daughters of Cecrops, from about 1616. Aglauros has just given way to temptation and taken the top off the basket entrusted to the sisters by Minerva, revealing the infant Ericthonius and a small snake inside. To the right is a fountain in honour of the Ephesian Artemis (Roman Diana), distinctive with her multiple breasts, each of which is a source of water. At the left, in the distance, is a herm, at the foot of which is a peacock, suggesting that Juno isn’t far away.

Rubens’ workshop is credited with this oil sketch of Cadmus Sowing Dragon’s Teeth from between 1610-90, the start of Ovid’s history of Thebes. Cadmus stands at the left, Minerva directing him from the air. The warriors are shown in different states, some still emerging from the teeth, others killing one another. Behind Cadmus is the serpent, dead and visibly edentulous.

His oil sketch of The Death of Semele from about 1620 reveals Semele pregnant on a bed and in obvious distress. Jupiter grasps his thunderbolt in his right hand, as his dragon-like eagle swoops in through the window.

Rubens’ Perseus and Andromeda (c 1622) shows a late moment when the height of action is just past, but its outcome more obvious. Andromeda is at the left, unchained but still almost naked. Perseus is in the process of claiming her hand as his reward, for which he is being crowned with laurels, as the victor. He wears his winged sandals, and holds the polished shield that still reflects Medusa’s face and snake hair. One of several putti (alluding to their forthcoming marriage) holds Hades’ helmet of invisibility, and much of the right of the painting is taken up by Pegasus, derived from a different version of the myth. At the lower edge is the dead Cetus, its fearsome mouth wide open.

The young and flourishing Rubens painted this remarkable Head of Medusa in about 1617. This shows the head after Perseus had placed it on a bed of seaweed once he had rescued Andromeda. He includes an exuberant mass of snakes, even a lizard and a scorpion, more of which appear to be forming in the blood exuding at the neck.

His superb The Rape of Proserpina (1636-38) shows a composite of Ovid’s account. Pluto’s face looks the part, his eyes bulging and staring at Minerva, who is trying to stop the girl from being abducted. Below the chariot, the basketful of flowers which Proserpine had been picking is scattered on the ground. Rubens shows irresistible movement to the right, as Pluto struggles to lift the girl into his chariot. Two winged Cupids are preparing to drive the black horses on, once the couple are secured inside.

Rubens’ surviving oil study of Pallas and Arachne (1636-7) tells this story in a conventional view. In the foreground, the angry Minerva is striking Arachne on the forehead with the shuttle. To the right is one of the images woven by Arachne, showing Europa riding Jupiter disguised as a white bull, an image that Rubens was familiar with from Titian’s Rape of Europa (c 1560-62), copied so well by Rubens in 1628-29. However, this version is different from either of those. Behind Minerva and Arachne, two women are sat at a loom, and it’s tempting to think that they too might represent the pair, in multiplex narrative. However, neither is dressed in red as is Arachne, leaving the question open.

His Tereus Confronted with the Head of his Son Itys (1636-38) shows the two sisters dressed as Bacchantes, one carrying her thyrsus with her left arm, and their breasts bared. Tereus is just reaching for his sword with his right hand, and his eyes are wide open in shock and rage. In the background, a door is open, and one of the court watches the horrific scene.

Rubens painted Boreas Abducting Orithyia in about 1620, when he was at the peak of his career. Boreas is shown in his classical guise, as a roughly bearded old man with wings. He is sweeping Orithyia up in his arms, while a cluster of Cupids are engaged in a snowball fight, a lovely touch of humour, and a subtle reference to winter.

This oil sketch of Aurora Abducting Cephalus was probably painted by Rubens in 1636-37, late in his life, for his workshop to complete as a painting for King Philip IV of Spain’s hunting lodge at Torre de la Parada, near Madrid. In addition to showing the willing Aurora trying to persuade the reluctant Cephalus to join her in her chariot, it includes some details differing from Ovid’s story: Diana’s hunting dog and javelin, given by Procris to her husband after their reconciliation, occurs later in the story, and may be intended as attributes to confirm his identity.

His oil sketch of Cephalus and Procris (1636-37), shows the couple just before Cephalus throws the fateful javelin at his wife.

Rubens’ initial oil sketch of The Fall of Icarus (1636) above, was presumably turned into a finished painting by his apprentice Jacob Peter Gowy. Icarus, his wings in tatters and holding his arms up as if trying to flap them, plunges past Daedalus. The boy’s mouth and eyes are wide open in shock and fear, and his body tumbles as it falls. Daedalus is still flying, though, his wings intact and fully functional; he looks towards the falling body of his son in alarm. They are high above a bay containing people with a fortified town at the edge of the sea.

In the previous article I looked at how RunningBoard monitored an ordinary notarized macOS app, but didn’t manage its life cycle by limiting its access to resources such as memory, CPU or GPU. Here I extend that to the two types of app that are most likely to be managed by RunningBoard, Catalyst and iPadOS apps.

Catalyst

Apple introduced this as a streamlined way for developers of iPadOS apps to be able to create a version that runs in macOS from Catalina onwards. When running on macOS, Catalyst apps are dependent on RunningBoard’s life cycle management, UIKitSystem (which first appeared in macOS Mojave) to bridge between UIKit’s class framework in iPadOS and those in macOS, and additional -board services including FrontBoard, FuseBoard and BaseBoard. Catalyst apps also have access to some features in AppKit, the central class framework for apps developed for macOS, at least until SwiftUI has started to replace it.

Although Apple might have had high hopes of Catalyst bringing many new apps from iPadOS, it hasn’t proved popular with third-party developers, and the ability of Apple silicon Macs to run iPadOS and iOS apps has reduced its relevance to users.

Job descriptions

RunningBoard’s lengthy job descriptions recorded in the log early during the app launch process allow regular macOS, Catalyst and iPadOS apps to be distinguished easily. At the start of each job description, the Platform is recorded, 1 for macOS, 2 for iPadOS, and 6 for Catalyst.

Other differences in job descriptions include:

• In EnvironmentVariables, iPadOS adds Container values for CFFIXED_USER_HOME and _DYLD_CLOSURE_HOME.
• In AdditionalProperties, both Catalyst and iPadOS apps have “Managed” set to true, and SpawnConstraints containing their CDHashes.
• In AdditionalProperties, iPadOS apps have a BeforeTranslocationBundlePath specified.

Catalyst launch

Catalyst apps are launched using the same basic sequence of events as regular macOS apps, with some additional overhead resulting from their UIKitSystem and -board service support. However, when they reach RunningBoard they become managed, in the test case denying it access to the GPU:
00.984295 com.apple.runningboard [app…] Memory Limits: active 0 inactive 0
00.984303 com.apple.runningboard [app…] This process will be managed.
00.984307 com.apple.runningboard <private> is not freezer eligible, disabling freezing.
00.985634 com.apple.runningboard [app…] Set jetsam priority to 0 [0] flag[1]
00.985649 com.apple.runningboard 3638 Set Darwin GPU to "deny"
00.985708 com.apple.runningboard 3638 setGPURole role to 2 (no effect for this process)
00.985715 com.apple.runningboard [app…] Disabled CPU monitoring
00.985716 com.apple.runningboard [app…] Reset CPU monitoring limits to defaults
00.985717 com.apple.runningboard [app…] Resumed CPU monitoring
where [app…] is the app identifier.

Later management includes regular state updates, such as
01.209325 com.apple.runningboard Update delivered for [app…] with taskState 4
01.209327 com.apple.runningboard Received state update for 3638 (app…, running-active-Visible

iPadOS launch

iPadOS and iOS apps are launched completely differently on macOS. Initially MIS, presumably MobileInstallationService, validates the app and its Wrapper, which are translocated to a hidden location in /private/var/folders, from where the wrapped app will be launched. Translocation isn’t intended as a security measure, as it is with macOS apps run there when in quarantine, but is required to work around two limitations:

• iOS/iPadOS apps may expect to be run from a path that doesn’t contain whitespaces. The path to the translocation folder guarantees that.
• In macOS, the user can run apps from (almost) any path, such as the Desktop, and can rename apps. The translocation path ensures the app’s name and path remain fixed.

Those are reflected in the following log entries, which have changed little since Big Sur:
00.946662 com.apple.mis Bundle: <private>
00.946662 com.apple.mis Is main executable: 0
00.953668 com.apple.syspolicy MIS validation result: 0
00.953673 com.apple.syspolicy Valid app wrapper: <private>
00.953719 com.apple.syspolicy appWrapperPolicyResult: <private>, AWPolicyResult: 1,1,0
00.956399 com.apple.securityd SecTranslocateCreateGeneric: created /private/var/folders/x4/[…]/d/Wrapper
00.965043 com.apple.launchservices LAUNCH: translocate to <private> from <private>
01.047816 com.apple.launchservices Marking <private> as .requiresSecureLaunch because it is PLATFORM_IOS or PLATFORM_MACCATALYST.
01.049878 com.apple.launchservices LAUNCH: _LSLaunchThruRunningboard: com.parrot.freeflight6 / <private>
FairPlay DRM is then accessed through the Secure Enclave Processor.

When it reaches the attention of RunningBoard, the app’s memory limits are set, it’s denied the GPU, and it’s then managed through its life cycle.
02.365127 com.apple.runningboard [app…:3466] Memory Limits: active 16384 inactive 16384
02.365137 com.apple.runningboard [app…:3466] This process will be managed.
02.365142 com.apple.runningboard <private> is not freezer eligible, disabling freezing.
02.365150 com.apple.runningboard Now tracking process: [app…:3466]
02.367347 com.apple.runningboard 3466 Set Darwin GPU to "deny"
02.367450 com.apple.runningboard 3466 setGPURole role to 2 (no effect for this process)
02.367460 com.apple.runningboard [app…:3466] Disabled CPU monitoring
02.367462 com.apple.runningboard [app…:3466] Reset CPU monitoring limits to defaults
02.367464 com.apple.runningboard [app…:3466] Resumed CPU monitoring
02.367496 com.apple.runningboard [app…:3466] set Memory Limits to Hard Inactive (16384)
where [app…:3466] is the app identifier.

That’s followed by frequent assertions and state updates.

PerfPowerServices

Some users have reported RunningBoard using high CPU %, sometimes associated with high levels from PerfPowerServices. By chance, during these tests I encountered a similar situation. For several seconds, the log was filled with entries recording com.apple.PerfPowerServices requesting management information from RunningBoard about most if not all services running at that time.

Many entry sequences followed the pattern:
00.004740 com.apple.runningboard PERF: Received request from [osservice<com.apple.PerfPowerServices>:976] (euid 0, auid 0) (persona (null)): lookupHandleForPredicate:error:
00.004743 com.apple.runningboard PERF: Received lookupHandleForPredicate request from [osservice<com.apple.PerfPowerServices>:976] (euid 0, auid 0) (persona (null))
00.004971 com.apple.runningboard _multiInstance = 0
00.004973 com.apple.runningboard _executablePath = /usr/sbin/cfprefsd
00.004974 com.apple.runningboard no additional launch properties found for <private>
00.005020 com.apple.runningboard _resolveProcessWithIdentifier pid 2712 euid 277 auid 277
00.005040 com.apple.runningboard Resolved pid 2712 to [osservice<com.apple.cfprefsd.xpc.agent(277)>:2712]
00.005089 com.apple.runningboard memorystatus_control error: MEMORYSTATUS_CMD_CONVERT_MEMLIMIT_MB(-1) returned -1 22 (Invalid argument)
00.005091 com.apple.runningboard memorystatus_control error: MEMORYSTATUS_CMD_CONVERT_MEMLIMIT_MB(0) returned -1 22 (Invalid argument)
00.007828 com.apple.runningboard Full encoding handle <private>, with data 44b0344500000a98, and pid 2712
00.008019 com.apple.runningboard [osservice<com.apple.cfprefsd.xpc.agent(277)>:2712] is not RunningBoard jetsam managed.
00.008040 com.apple.runningboard [osservice<com.apple.cfprefsd.xpc.agent(277)>:2712] This process will not be managed.
for multiple copies of cfprefsd, and many other processes.

Presumably PerfPowerServices is concerned with performance power services, but the purpose of these many requests is unknown. After a few seconds of frenetic activity, and more than 10,000 log entries, this subsided and normal running was resumed. If anyone can provide an explanation, I’d be most grateful.

Key points

• RunningBoard job descriptions record the app Platform: 1 for macOS, 2 for iPadOS, and 6 for Catalyst.
• Catalyst apps are managed by RunningBoard through a relatively normal launch sequence.
• iPadOS/iOS apps are launched differently, in a Wrapper and translocated to avoid problems with their name and path in macOS.
• iPadOS/iOS apps rely on FairPlay DRM accessed through the Secure Enclave.
• iPadOS/iOS apps have memory limits imposed by RunningBoard.
• PerfPowerServices can busy RunningBoard with many requests and high CPU %. The cause is unknown, but that high activity should settle of its own accord.

From the start of his career, Lovis Corinth was a great admirer of the paintings of Rembrandt, and like him he painted a series of self-portraits reflecting changes in his life. This penultimate article in the series to commemorate his death a century ago looks at a selection of those. These should cast light on whether his style changed dramatically over the course of his career, and what effects his stroke at the end of 1911 may have had on that style.

His earliest self-portrait is typical of his initial detailed realist style, although he didn’t show the meticulous detail in his hair or beard, for instance, that was more popular earlier in the nineteenth century.

By his later years in Munich, the skin of his face has become more painterly, and non-flesh surfaces such as his shirt and the landscape background, as well as the skull, have obviously visible brushstrokes. A simple self-portrait was also not enough: he posed beside a skeleton, drawing the comparison between his living, fleshy face, and the fleshless skull next to it.

His move from Munich, where he already had a reputation for drinking and social life, to Berlin brought him love and inspiration from his fiancée then wife Charlotte Berend, but intensified his work, social life, and drinking. His depiction of flesh has a rougher facture, and most of the passages in this work appear to have been sketched in quickly.

These changes are even more evident in this wild and ribald double portrait with his wife, posing appropriately as Bacchantes. His chest and left arm now have stark dark brushstrokes giving the flesh a texture rather than form.

Before his stroke, and the outbreak of the First World War, he posed as the standard-bearer to a mediaeval knight, his head held high with pride for Prussia. The flesh of his face now appears rough-hewn, particularly over surfaces that would normally be shown smooth and blended, such as the forehead. Bright patches on the suit of armour are shown with coarse daubs of white paint.

After his stroke, and just as the First World War was about to start, there has been little roughening in his facture. His face, though, looks more worried, and his previous pride appears to have been quashed.

By the end of the war, when he was 60, he had aged markedly, with receding hair and gaunt cheeks. Although his face and hand are as sketchy as before, his hair and left ear have been rendered more roughly still.

When he was out in the country sun at the family’s chalet by Walchensee, he painted his clothing and the landscape extremely roughly. He looks his years, but if anything appears more healthy and relaxed than when he was confined to Berlin.

His last self-portrait shows age catching up with him, and has even rougher facture. His forehead is now a field of daubs of different colours, applied coarsely. His hair consists of gestural marks seemingly made in haste.

Although there’s a clear trend towards a rough facture over the years, I can’t see any particular watershed either following his stroke or at another time that suggests sudden change. Can you?

References

Wikipedia.

Lemoine S et al. (2008) Lovis Corinth, Musée d’Orsay & RMN. ISBN 978 2 711 85400 4. (In French.)

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

1: From PageRank and 10^100 to a set of letters.

2: A hooligan went from directory to search then declined into finance and news.

3: After changing name three times, this directory has gone wavy.

The common factor

I look forward to your putting alternative cases.

This is the last batch of ‘simple’ updates to my free apps to bring them up to the expectations of macOS 26 Tahoe. With them comes a minor update to my log browser LogUI, which is recommended for all using Tahoe, as it fixes an annoying if fundamentally cosmetic bug.

Preparing these updates for release was a little troublesome, as I attempted this using developer beta 3 of Tahoe and Xcode 26 beta 3. Little did I realise when I got all four rebuilt, tested and notarized, that this combination had stripped their shiny new Tahoe-compliant app icons. That made these new versions unusable in Sequoia and earlier, as they each displayed there with the generic app icon, despite working fine in Tahoe.

Eventually I discovered that I could build fully functional versions using Xcode 26 beta 2 in Sequoia 15.5, so that’s how they have been produced.

File integrity

Five years ago I build a suite of two apps and a command tool to enable checking the integrity of file data wherever it might be stored. This uses SHA256 hashes stored with each checked file as an extended attribute. At that time, the only alternative saved hashes to a file in the enclosing folder, which I considered to be suboptimal, as it required additional maintenance whenever files were moved or copied to another location. It made more sense to ensure that the hash travels with the file whose data integrity it verifies.

The three are Fintch, intended for use with single files and small collections, Dintch, for larger directories or whole volumes, and cintch, a command tool ideal for calling from your own scripts. As the latter has no interface beyond its options, it continues to work fine in macOS 26.

Since then other products have recognised the benefits of saving hashes as extended attributes, although some may now use SHA512 rather than SHA256 hashes. What may not be apparent is the disadvantage of that choice.

Checking the integrity of thousands of files and hundreds of GB of data is computationally intensive and takes a lot of time, even on fast M4 chips. It’s therefore essential to make that as efficient as possible. Although checksums would be much quicker than SHA256 hashes, they aren’t reliable enough to detect some changes in data. SHA algorithms have the valuable property of amplifying even small differences in data: changing a single bit in a 10 GB file results in a huge change in its SHA256 hash.

At the same time, the chances of ‘collisions’, in which two different files share the same hash, are extremely low. For SHA256, the probability that two arbitrary byte sequences share the same hash is one in 2^256, roughly one in 1.2 x 10^77. Using SHA512 changes that to one in 2^512, which is even more remote.

However, there ain’t no such thing as a free lunch, as going from SHA256 to SHA512 brings a substantial increase in the computational burden. When run on a Mac mini M4 Pro, using its internal SSD, SHA256 hashes are computed from files on disk at a speed of around 3 GB/s, but that falls to 1.8 GB/s when using SHA512 hashes instead.

Dintch provides two controls to optimise its performance: you can tune the size of its buffer to cope best with the combination of CPU and storage, and you can set it to run at one of three different QoS values. At its highest QoS, it will run preferentially on Apple silicon P cores for a best speed of 3 GB/s, while run at its lowest QoS it will be confined to the E cores for best energy economy, and a speed of around 0.6 GB/s for running long jobs unobtrusively in the background.

The two apps and cintch are mutually compatible, and with their earlier versions going back to macOS El Capitan. In more recent versions of macOS they use Apple’s CryptoKit for optimum performance.

Dintch version 1.8 is now available from here: dintch18
Fintch version 1.4 is now available from here: fintch14
and from their Product Page, from where you can also download cintch. Although they do use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with earlier versions.

Compression/decompression

Although I recommend Keka as a general compression and decompression utility, I also have a simple little app that I use with folders and files I transfer using FileVault. This only uses AppleArchive LZFSE, and strips any quarantine extended attributes when decompressing. It’s one of my testbeds for examining core allocation in Apple silicon Macs, so has extensive controls over QoS and performance, and offers manual settings as well as three presets.

Cormorant version 1.6 is now available from here: cormorant16
and from its Product Page. Although it does use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with version 1.5 and earlier.

LogUI

Those using this new lightweight log browser in Tahoe will have discovered that, despite SwiftUI automatically laying out its controls, their changed sizes in Tahoe makes a mess of the seconds setting for times. This new version corrects that, and should be easier to use.

LogUI version 1 build 70 is now available from here: logui170

There will now be a pause in updates for macOS Tahoe until Apple has restored backward compatibility of app icons, hopefully in the next beta-releases.