Kakarottoxxxx: 三年前，我开始开发 macOS 休息提醒工具 Eye Monitor ，目前这款应用已经常驻在 App Store 健康榜的前三位。

Eye Monitor 的设计初衷是因为本人常常面对电脑一工作就是 3 、4 小时不停歇，长时间的用眼和久坐导致我在某个时期视力下降明显以及出现腰酸的现象。

Eye Monitor 工作原理很简单：它通过你在 Mac 上的鼠标移动和键盘使用来自动识别你是否在使用电脑，并在长时间使用后弹出弹窗提醒你休息。所以你不需要手动地设置提醒。

这三年进行不少功能迭代，其中我最喜欢的功能有三个：
1 、数据报表：可以查看历史上使用时长、休息完成率等数据的趋势，并且数据可以通过 iCloud 同步，也可以下载到本地
2 、自定义全屏弹窗的壁纸和提示词：颜值即正义
3 、iOS 提醒：我发现自己常常在 Eye Monitor 提示我休息后离开电脑开始玩手机，可以称之为“假休息”。所以我也写了一个 iOS 版本，用来接收 Mac 的提醒并在手机上也弹出提醒，这样可以让我回头是岸。


清华大学有句口号叫做“为祖国健康工作五十年”，希望大家共勉之。

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

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

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

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

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

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

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

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

2000-2016 text logs

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

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

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

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

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

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

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

2016 Unified log

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

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

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

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

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

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

Privacy

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

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

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

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

Problems

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

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

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

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

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

elvea:

XDM ，这 2 天一直会出现电脑重启后，代理被自动设置了，IP 是 62.3.13.112 和 193.3.177.225 ，端口是 8000 ，有点怀疑是不是中毒了，有什么建议吗，大家。现在电脑都不怎么敢用了

mayhew33: mac （ intel ）版本的 quantumultX YouTube 可以打开 点开视频播放一段时间后就刷新不出来了
每刷一个视频都是这个情况
但是 YouTube 的网页可以进
其他平台的视频都没有影响 只有 youtube
ps：配置文件和 ios 用的一样的 ios 没有这样的问题； 另外 mac 的 mitm 没打开

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

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

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

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

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

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

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

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

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

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

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

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

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

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

taskpolicy

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

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

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

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

Virtualisation

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

Game Mode, CPU cores

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

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

Summary

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

Explainer

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

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

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

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

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

Click for a solution

Activity Monitor

Keeps an eye on (monitor) exercise (activity) for checking 2, 3, memory and more (what Activity Monitor does).

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

Click for a solution

CPU

Champion’s reward (a cup) in disarray (rearranged to cpu) for the heart of your Mac (its CPU), shown in 1 (it is).

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

Click for a solution

Cache

Endless high status (cachet without the last letter) in hiding place for treasure (a cache) can be shown in 1 (when Content Caching service is enabled, it’s one of the tabs or panes in Activity Monitor).

The common factor

Click for a solution

The latter two are tabs or views in the first.

I look forward to your putting alternative cases.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

neochen13:

纯写代码用的……没有其他更多用途，撑死看点视频

预算囊中羞涩，希望能够 2000 内……

谢谢各位佬们

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

1: This Scot with a volume was a notebook closed in 2019.

Click for a solution

MacBook

This Scot (Mac) with a volume (book) was a notebook closed in 2019 (it was a notebook Mac discontinued in 2019).

2: Ledger for baptismal water manages typefaces.

Click for a solution

Font Book

Ledger (book) for baptismal water (a font) manages typefaces (what this app does).

3: Root -1 with bound paper as a companion to the iMac with a handle.

Click for a solution

iBook

Root -1 (in maths, i) with bound paper (a book) as a companion to the iMac (it was) with a handle (it’s one of the few computers that features a handle).

The common factor

Click for a solution

They each include the word book into their name.

I look forward to your putting alternative cases.

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

1: This Scot with a volume was a notebook closed in 2019.

2: Ledger for baptismal water manages typefaces.

3: Root -1 with bound paper as a companion to the iMac with a handle.

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.

Among those things that never change in the Finder is a prominent bug that has affected its column view for at least the last 11 years, back to OS X Mavericks if not before. During beta-testing macOS Sequoia last summer, I thought for a while that Apple had fixed it, but when I looked for the bug in the release version of macOS 15.0 it hadn’t even gone into hiding, and it’s still there today in 15.1.1.

I must have written about it here for the first time back in 2015, and for a while checking for it became an annual event, but over the last few years there seemed little point in whingeing about it any more. No one seemed bothered that the Finder couldn’t handle its column views properly, as Apple silicon Macs are so much more exciting. Every so often it comes back to bite me, and I’m reminded how annoying it is, so please bear with my catharsis.

Like many of the most persistent and annoying bugs, the Finder column width bug might seem tricky to reproduce, but when you normally work in column views it will return to haunt you.

It’s straightforward to demonstrate. Open a new window in the Finder, and ensure it’s set to Column View. Select your Documents folder in the sidebar, then select another folder containing more files and folders in the first column, within Documents. It helps if some of those have long names, so they’re truncated using an ellipsis … in the name.

Now click on your Applications folder in the sidebar to switch to that. Select an app, ideally one with a long name that has also been truncated with an ellipsis.

Then click on the Back button to switch back to your previous view of the folder within Documents. More often than not, you’ll now see the second column fill the remaining width of the window, and browsing any deeper into those folders is almost impossible, as the column width settings have gone haywire.

The simple way to recover is to select a different folder in the first column, which should restore orderly column widths.

While this might appear to be obscure, and unlikely to trouble anyone in normal use, there’s one situation that causes it to occur frequently, when you like to park your Finder windows in column view, with two columns shown in the view, as in the first screenshot above. Because of this I have changed my behaviour over the last few years, and now leave Finder windows with just the first column filled, a solution I worked out over four years ago. But any lapse in concentration allowing me to park a window in the wrong configuration makes it likely the bug will return and bite back.

Over those 11 years, governments have come and gone, my grandchildren have grown up and one is now at university, we survived Covid, lost QuickTime and 32-bit code, and now use Apple silicon Macs. But one thing has remained unchanged through all of that, the Finder column width bug.

Whether you’re a developer or user, gaining an understanding of how macOS manages the cores in an Apple silicon CPU is important. It explains what you will see in action when you open Activity Monitor, how your apps get to deliver optimal performance, and why you can’t speed up background tasks like Time Machine backups. In this series (links below) I’ve been trying to piece this together for the M4 family, and this article is my first attempt to summarise as much of the story as I know so far. I therefore welcome your comments, counter-arguments and improvements.

Scope

For the purposes of this article, I’ll consider a single thread that macOS is ready to load onto a CPU core for execution. For that to happen, five decisions are to be made:

• which type of core, P or E,
• which cluster to run it in,
• which core within that cluster,
• what frequency to run that cluster at,
• the mobility of that thread between cores in the same cluster, and between clusters (when available).

Which type of core?

Since the early days of analysing M1 CPUs, it has been clear that the choice between P and E core types is made on the Quality of Service (QoS) assigned to the thread, availability of a core of that type, and whether the thread uses a co-processor such as the AMX. For the sake of generality and simplicity, I’ll here ignore the last of those, and consider only threads that are executed by the CPU alone.

QoS is primarily set by the process owning that thread, in the setting exposed to the programmer and user, although internally QoS is modulated by other factors including thermal environment. Threads assigned a QoS of 9 or less, designated Background, are allocated exclusively to E cores, while those with higher QoS of ‘user’ levels are preferentially allocated to P cores. When those are unavailable, they may be allocated to E cores instead.

This can be changed on the fly, reassigning higher QoS threads to run on E cores, but that’s not currently possible the other way around, so low QoS threads can’t be run on P cores. The sole exception to that is when run inside a virtual machine, when VM virtual cores are given high QoS, allowing low QoS threads within the VM to benefit from the speed of P cores.

Which cluster?

M4 Pro and Max variants have two clusters of P cores, so the next decision is which of those to run a higher QoS thread on:

• if both clusters are shut down, one will be chosen and its frequency brought up;
• if one cluster is already running and has sufficient idle residency (‘available residency’) to accommodate the thread, that will be chosen;
• if one cluster already has full active residency, the other cluster will be chosen;
• if both clusters already have full active residency, then the thread will be allocated to the E cluster instead.

This fills an active P cluster before allocating threads to the inactive one, and fills both P clusters before allocating a higher QoS thread to the E cluster.

Cluster allocation is of course simpler on the base M4, where there’s only one E and one P cluster. Should Apple make an M4 Ultra as expected, then that would not only have four P clusters, but two E clusters. Until that happens, we can only speculate that similar would then apply, including the E clusters.

Which core within the cluster?

This is perhaps the simplest decision to make. If there’s only one core with available residency in that cluster, that’s the only choice. Otherwise macOS picks an arbitrary core from those available, apparently to ensure roughly even use of cores within each cluster.

What frequency?

For the E cluster, choice of frequency appears straightforward, with low QoS threads being run at minimum E core frequency of 1,020 MHz or slightly higher, and higher QoS threads spilt over from fully occupied P clusters are run at E core maximum frequency of 2,592 MHz.

P cluster frequency appears to be determined by the total active residency of that cluster after the new thread has been added. When that’s the only thread running in that cluster, maximum frequency of 4,512 MHz is chosen, but rising total active residency reduces that in steps down to about 3,852 MHz when all the cores in the cluster are at 100% active residency. In most cases, the big reduction in frequency occurs when going from about 200% to 300% total active residency. This currently appears to be part of a strategy to pre-emptively minimise the risk of thermal stress within the chip.

Thread mobility

Once the thread has been loaded into a core in the optimal cluster running at the chosen frequency, it’s likely to be moved periodically, both to any other free core within that cluster, and to another cluster, when available. While this does occur in previous M-series CPUs, it appears particularly prominent in M4 variants.

Movement of threads within a cluster can occur quite frequently, every 0.1 second or so, particularly within the E cluster. Movement between clusters occurs less frequently, about every 4-5 seconds, and would only occur when the other cluster is shut down or idle, so free to run all the threads of the current cluster. This is most probably to ensure even thermal conditions within the chip.

Summary

The whole strategy is shown in the following diagram, also available as a tear-out PDF from here: m4coremanagement1

Previous articles

Inside M4 chips: P cores
Inside M4 chips: P cores hosting a VM
Inside M4 chips: E and P cores
Inside M4 chips: CPU core performance
Inside M4 chips: CPU power, energy and mystery
Inside M4 chips: Matrix processing and Power Modes
Inside M4 chips: Controlling frequency

Explainer

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

In case the message isn’t clear yet, third-party kernel extensions are on their way out, particularly in Apple silicon systems. Although macOS continues to extend the capabilities of its kernel using nearly 700 of them, for almost all purposes user apps and devices should now have switched to using modern system extensions and their equivalents. This article considers how you can clean your Mac of those old kernel extensions (kexts), particularly in preparation for a new Mac.

The problem

In the past kexts have been used widely to support third-party hardware and features like software firewalls and security protection. Because those run at a highly privileged level, in what’s known as Ring 1, they have been a well-known cause of instability leading to kernel panics. They also provide malicious software with an opportunity to wreak havoc at the highest level. Replacing kexts with system extensions run at a user level should improve both stability and security, although experience shows that the first of those isn’t yet guaranteed, as macOS support for system extensions hasn’t been as free of bugs as it should have been, and sometimes has caused kernel panics.

From Big Sur onwards, the previous scheme of prelinked kernels has changed to use kext collections pooling kexts to be loaded into one of three:

• The Boot Kext Collection (BKC), on the Sealed System Volume in /System/Library/KernelCollections (Intel Macs) or the Preboot volume (M-series Macs). This is the equivalent of the old prelinked kernel, and contains the kernel itself, and all the major system kernel extensions required for a Mac to function. This is typically about 65 MB in size on Intel.
• The System Kext Collection (SKC), also on the Sealed System Volume of Intel Macs in /System/Library/KernelCollections, but not used on Apple silicon models. This contains other system kernel extensions, loaded after booting with the BKC, and typically around 370 MB.
• The Auxiliary Kext Collection (AKC), stored on the Data volume in /Library/KernelCollections when it exists, is built and managed by the service kernelmanagerd. This contains all installed third-party kernel extensions, and is loaded after the other two. In Full Security mode on Apple Silicon there’s no AKC.

Cleaning up old kexts is a valuable move even if you’re not intending to migrate to an Apple silicon Mac, and has grown in importance with newer Macs. For a kext to be used on an Apple silicon Mac its boot security has to be reduced, third-party kexts must be enabled, and each one installed with authorisation through Privacy & Security settings, something you’ll probably want to avoid.

Uninstalling kexts

Before going any further, you need to check each of the kexts installed on your Mac to ensure that it can now be safely removed, either because there’s a better substitute, or because they have simply become orphaned. In many cases, on older Macs, kexts currently installed aren’t used at all, but have been abandoned there.

As you may be aware, kexts are now found in two different locations. They should have been originally installed by the app they came with, and saved first to /Library/Extensions. macOS then normally copies them from there to a folder nested inside /Library/StagedExtensions. That presents a further problem, as the latter are protected by SIP and can’t be tampered with. Cleaning up old kexts might thus appear an impossible task.

The good point about /Library/StagedExtensions is that its contents are structured to inform you of where the original kext came from: if it’s in /Library/StagedExtensions/Applications, then the kext was installed by that app, otherwise its folder path should lead you in the right direction.

For kexts installed by an app, or its installer, the responsibility for removing that kext rests with the app or its dedicated uninstaller. Apps that use kexts have to install them before use, for which most run scripts to move or copy the kext into the /Library/Extensions folder. They will then use additional scripts to update or remove that kext, that should save you the trouble. First visit that app’s support pages, and consult the procedure described there for uninstalling it. If the copy you have installed on your Mac isn’t the current version, you are likely to be advised to update to that latest version in order to uninstall it correctly.

Orphaned kexts

When a kext appears to have become orphaned from its app, or perhaps was installed independently, you’ll need to remove it manually. The steps required are:

• Delete all apps and services that might try to use that kext, and any other kexts that might depend on it.
• Unload the kext.
• Delete the kext from the /Library/Extensions folder.
• Restart to allow the auxiliary kext collection to be rebuilt.

It’s important to remove the app and any services that might try using that kext, as some might even try to reinstall it if they’re run. Others that might be run from LaunchAgents or LaunchDaemons could get into difficulties without the kext. Good uninstall scripts should deal with this thoroughly without you having to resort to looking for yourself.

Kexts are now unloaded using a command of the form
sudo kmutil unload -b [bundle-identifier]
or
sudo kmutil unload -p [bundle-path]
where bundle-identifier is a reverse URL like com.highpoint-tech.kext.HighPointRR, or the bundle-path is similar to /Library/Extensions/HighPointRR.kext. kmutil is the replacement for the old kextunload command. Although you could still use the latter, it will merely call kmutil to do its work.

With the kext unloaded, you can then delete it from its accessible location in /Library/Extensions. macOS controls its own staged copy in /Library/StagedExtensions, which it ultimately may get around to removing as well. If you want to remove all kexts from the staging directory, use the command
sudo kmutil clear-staging
although that will also clear any that you might still need, and could require those to be reinstalled.

With those cleared away, you’re ready to restart, which should trigger macOS to rebuild the auxiliary kext collection containing third-party kexts before they’re loaded during the restart. If the auxiliary kext collection isn’t rebuilt correctly, you can force that with the command
sudo kmutil rebuild
and authorising that, followed by restarting the Mac to bring those changes into effect.

You can then check to see if that kext has been loaded using the command
kmutil showloaded --collection aux
to list all loaded kexts in the auxiliary kext collection.

Migration to Apple silicon

Not only is Migration Assistant reluctant to try installing kexts on your new Mac, because of their requirements for use on Apple silicon Macs, it’s unable to enable and load any kexts. However, if you do need to use kexts on an M-series Mac, you’re going to have to enable them first using Startup Security Utility in Recovery Mode, then run the app’s install sequence and authorise them in Privacy & Security settings. That isn’t something that can happen behind your back, and without changing boot security settings no third-party extensions can be loaded. By default, your new Mac should start as clean as a whistle.

Summary

• This is a good time to clean up old kernel extensions on your Mac.
• Where possible, follow instructions for their removal provided on their support site.
• Use an app’s uninstall feature, or its uninstaller, if provided.
• Manual uninstalls require deletion of apps and code relying on that kext, unloading using kmutil, deletion from /Library/Extensions, and restarting.
• Don’t worry about what may be left behind in /Library/StagedExtensions.
• Old kexts can’t be enabled automatically by Migration Assistant for an Apple silicon Mac.

Further reading

Installing a kernel extension (Apple)
Installing system extensions and drivers (Apple)

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

Claude (Anthropic) 最近出了个 MCP (Model Context Protocol，模型上下文协议) 协议，让我朋友圈有刷屏之势，能清晰感受到，大伙儿都非常欣喜。我自己试用之后，决定写下这篇文章，分享给你。

MCP 是一种新的开放标准协议，用来在大模型和数据源之间建立安全双向的链接。这是它的官方示意图。

这张图展示了使用 Claude 或其他 IDE 时，通过这种双向沟通协议，模型（目前指 Claude）可以与不同的数据服务器进行连接。每个连接的数据源可能千差万别，比如上图里面前两个连接本地数据，第三个则直接通过互联网操作远程文件。

MCP 有什么用？为什么会让这么多开发者与用户欢欣鼓舞？

MCP 是一种统一的集成方式，交互界面完全一致。如果其他大模型也跟进，那么以后连接数据的感觉，就像给不同的电子设备使用 USB-C 接口，而不用准备那么多种不同的线缆插头。

更重要的是 MCP 的设计目标——提升安全性与控制力。因为以前处理数据时，我们通常采用极端的处理方式，很不安全。

第一种是将数据上传到大模型的对话中。这会带来两个问题：

另一种方式是让大模型获得本地管理员级别处理权限，帮助我们自动处理本地数据。之前我 给你介绍过的 Open Interpreter 就属于这种方式。看起来非常方便、灵活，但 AI 代理在本地以管理员权限进行各种操作，看到所有文件。如果它被植入不安全的代码，控制你的计算机，可能导致隐私和重要数据泄露，后果严重性不言而喻。

为解决上述两种极端数据交互方式带来的问题，Claude 提供了 MCP 作为一种解决方案。作为协议，它是完全开放的。后续其他主流 AI 企业能否跟进，咱们说不准。但是现在就可以用 Claude 来体验一下 MCP 带来的数据交互好处。

我们先沿着官方的 参考资料有快速上手指南 操作一下。指南非常简洁，步骤清晰，跟着做并不难。

官方教程给出了一个最简单的数据操作样例，是一个 SQLite 数据库。

SQLite 设置非常简单，单文件即可运行。我讲数据库课程超过 10 年，一直用的就是 SQLite。学生不用一上来就去学习架设服务器、权限管理，而是直接拿过来就可以学习 SQL 查询语句。对文科生来说，这都是一个非常简单的界面。

在上手教程里，我们会操作一个本地 SQLite 文件，与 Claude 进行交互。我们需要预先安装一些软件，不过很简单，你照着指南里面这个命令拷贝到终端执行就行。

下面是在我电脑上执行过程截图。

当然别忘了，你需要 下载 Claude Desktop 应用的最新版本，这是执行后续操作的前提。

之后，你需要建立一个 SQLite 的数据库样例文件。咱们先按照官方的设定来操作，复制页面上的这段代码，直接在终端执行就能搞定。

只要没有报错，你就拥有一个本地的 SQLite 样例数据了。

它存储在你的用户目录下，叫做 test.db .

下面你需要做的，是本次教程里最为不方便的操作——修改 Claude 配置文件。我相信在未来的版本当中，这个操作是能够通过图形化的界面来拖拽完成的。不过现在还是原型系统，你暂且忍耐一下。教程里明确告诉你设定文件的路径，你照着这个来执行就好。

你可以用 Visual Studio Code 或者类似的编辑器打开指定的配置文件路径。我这里用的是 Cursor。打开该文件后，你需要把教程代码段里的内容填进去。

不过这里有一个注意事项——你需要把原先代码中的 username 换成你自己在 macOS 上实际的用户名。这个很重要，不然连不上数据，会耽误你很多宝贵时间查错……别问我怎么知道的。

之后注意，你需要在 macOS 上重启你的 Claude Desktop App。

到此，设定就算完成了。

下面，咱们实际看看 Claude 是如何与 test.db 这个数据文件交互。官网给出的流程图是这样的：

如图所示，Claude 先要和我们刚刚搭建的 SQLite MCP 服务之间建立连接，然后可以执行查询的操作。

首先，我们先用提示词来把这二者连接起来。这里的提问我是直接从人家官方的快速开始教程里面照抄的——「你能不能连接我的 SQLite 这个数据库，然后告诉我哪些商品现在可售，以及他们的售价？」

Can you connect to my SQLite database and tell me what products are available, and their prices?

Claude 立即就会明白需要和 SQLite MCP 沟通。

然后它就找我们要权限。我选择这一整次对话都可以给它开放权限（Allow for This Chat）。注意，这就是我刚刚跟你提到的安全性——大模型要做什么操作、找我们要什么样的权限、权限开放的时间范围多大……我们都可以自己来控制。

大模型开始与 MCP 通讯，执行一系列的 SQL 语句，通过查询返回结果。

注意，Claude 不像 SQLite 简单给你返回一个表格作为结果，而是用自然语言回答你的问题。这个样例中，它把现在可售商品都给你列出来，并且后面都标上价格。这种交互就显得非常自然。

下面我们来继续提出另一个样例问题——「在你的数据库中，商品平均价格是多少？」

What’s the average price of all products in the database?

这次大模型没有找我们再要权限。因为刚刚已经说明，整轮对话，它都可以获得 MCP 服务数据的操作权限。

执行后，Claude 告诉我们，平均值为 82.14 美元。

你会发现我们刚刚一直用英文来提问，这是因为教程是英文的，咱们为了方便拷贝了问题。但对 Claude 来说，中文完全不是问题。用中文来问「你能分析价格分布并提出任何定价的优化建议吗？」Claude 就会用中文来答。当然，背后还是连接 MCP 服务，调用 SQL 进行查询。

当查询遇到问题时，Claude 会自动反思，并且重组查询式，依照 MCP 服务返回的 SQLite 查询表格结果，告诉你不同的价格分布。

基于这些分析结果，它会给出优化建议，如价格策略、产品组合、促销策略和定价心理学应用等。

注意这是你单独用 SQLite 查询数据库无法直接给出的结果，SQLite 只能给出表格。而根据背景知识对查询结果表格进行解读，才是大模型的能力体现。

既然跑通了官网给出的样例，我们接下来换上我讲数据库课程时常用的样例数据集，叫做 colleges。这个数据集来自斯坦福大学的一门 MOOC，包含学生申请大学的模拟数据。

数据集包括三个表格：apply（谁申请了哪个学校的哪个专业，是否被录取）、colleges（所有大学的列表）和 students（所有学生的信息）。

平时上课时，我在这几个表之间来回操作，教学生如何跨越表格综合信息返回正确的结果。

这次，咱们不用任何的 SQL 命令撰写，而是直接用自然语言来提问。首先，你要确保 MCP 连接成功。注意你需要修改配置文件里，数据库文件的路径，指向 colleges.db 。

对了，之后别忘了重启 Claude Desktop。

我的问题为：「你能否连接我的 SQLite 数据库，并告诉我里面有什么？」

Can you connect to my SQLite database and tell me what’s in it?

还是索要了一系列权限后，Claude 告诉我们有三个表：college、student、apply。

之后，通过进一步查询，Claude 为我们介绍 college 表中有哪些字段，student 和 apply 表又分别有哪些字段。至此意味着 MCP 数据连接成功。

Claude 会给出一些建议，告诉你可以问哪些问题。

不过我还是用自己的问题好了：「哪些同学报考了 Stanford 并且被录取？」

Claude 通过 MCP 执行查询，告诉我 Amy、Fay、Jay、Helen 这几个学生被斯坦福大学录取，并且说明了他们的 GPA 和专业信息。

Claude 特别指出，「有意思的是」被录取的学生中，两名被计算机科学专业录取，两名被历史专业录取，大多数学生 GPA 都很高，3.7 以上，但也有一位学生 GPA 较低，仍被历史专业录取。2.9 的 GPA 也能被斯坦福录取，这确实「很有意思」。

接下来咱们问它第二个问题：「哪些学生没有被任何学校录取，是因为分数太低吗？」

Claude 返回了两个学生的信息，并且说明 Bob 申请了 Berkeley 的生物专业，而 Craig 申请了 MIT 的计算机科学专业。

它总结说，这些没被录取的学生 GPA 其实不低，这表明 GPA 其实不是唯一的录取标准。然后 Claude 甚至还专门给出了报考大学的方法建议。

如果单单使用 SQL 查询，你不可能获得这些建议，这也是利用大模型做数据分析的有趣之处。Claude 通过 MCP 把当前的 SQL 查询结果与申请美国大学的背景知识有机地联系起来，厉害不？

但实际上，它的回答是错的。

我教了十多年数据库课，对这个数据集非常熟悉。这里有一个陷阱——这个数据库里，有的学生没有申请任何一所大学。你不申请大学，当然不可能被任何一所大学录取，对吧？因此，在回答这个问题的时候，你的查询不能只看那些全部申请都被拒的学生。

所以我进一步提示它：

注意被所有申请的学校拒绝和没有被任何一所学校录取是不一样的。

我只提示到这，并没有说「有的学生没有申请学校」。但 Claude 很聪明，马上反应过来。它依然先找出所有提交过申请但没被录取的学生状况。后来它说，「让我们看看数据库中还有哪些学生是完全没有提交任何申请的」。注意这个查询，是它自己总结出来的。

综合分析后，它的答案是：刚才答案中那两个没有问题，是申请后却被所有申请的学校拒绝的学生；但还有若干完全没有提交申请的学生，分别是 Doris、Amy、Gary 和 Edward。

它还补充道，「这确实是两种完全不同的情况。谢谢您的纠正」。

很懂礼貌嘛，孺子可教。

Claude MCP 给我们带来的，绝不只是查询更简单、结果更全面、数据更安全这样的优势。至少，它打破了 Claude 处理数据长度和类型的限制。在 Claude 对话里，你想上传文件，就会看到限制——最多五个文件，每个文件不得超过 30 兆。

我找了一个上课时用到的数据库叫 movie.db。这个数据库包含了若干年的电影信息，虽然只有 246.7 兆，但这样的文件想在现在的 Claude 对话当中使用，那断然是不可能的。

你上传不上去，不仅仅是因为它体积太大，更是由于这种 .db 格式 Claude 就不允许上传，你连选择它都没有机会。

这些文件都是灰色的，不能点选。但是现在不一样了，我们直接把配置 MCP 路径修改成 movie.db，然后来连接。

Claude 找出这里面有三张表，分别包括了电影、演员和他们饰演角色的记录。

我问：「有多少女演员同时出演过《哈利・波特》电影的前两部？」你不要小看这个问题，你首先得知道《哈利・波特》电影的前两部都是啥。Claude 查询经过一些波折，但它非常勤恳地重构查询，然后告诉我们，这两部电影分别是《哈利・波特与魔法石》和《哈利・波特与密室》。

之后它列出了 8 个同时出现在两部电影中女演员的名单，还介绍了这个系列中的主要角色，如赫敏和麦格教授。我觉得这个回答非常好。

如果你在学习 SQL，那么还可以打开它的中间分析过程来查看完整 SQL 语句。

你可以自己用 SQLite 工具来验证查询结果。但更多时候，你兴许能从它的答案中得到参考和借鉴。

我必须说明一点——本文所演示的内容，只是 MCP 能力的冰山一角。MCP 现在支持的数据服务，就已包括 GitHub、Google Drive、Slack 等。

甚至，你还可以用十几分钟的时间，干脆构建一个自己的 MCP 服务。官网分别提供了 Python 和 Typescript 语言版本的对应教程。

而仅从 SQLite 的样例看，MCP 目前就可以连接本地数据库，不用像原先那样把整个数据来回上传下载。安全性和控制力比以前显著增强。

Claude 通过 MCP 作为中介，能很好地分析 SQLite 的数据集。在咱们展示的例子中，MCP 的优点是把大模型和数据有机结合起来——通过对外部世界规律的微妙体悟，在真实任务中有效帮助你充分利用自己的数据。

提示词的清晰度依然很重要。例如刚才提到的「申请了学校但没有被录取」和「完全没有申请学校」这样的问题，有时还需要我们引导一下。

试想我们把不同的数据来源综合起来，在一个对话中综合调用，这种感觉像更是一种「化学反应」，想想就让人兴奋。希望 MCP 的出现，能激发你的创意，让你利用多元数据集获得更为深入的洞察。

还是那句话，「临渊羡鱼不如退而结网」。与其看个热闹，不如自己动手试一试。哪怕你只是按照 Claude 官网的教程走一遍也好，相信也能获得更为直接的感悟。

欢迎你把自己尝试 Claude + MCP 的结果分享在留言区，我们一起交流讨论。

祝 AI 辅助数据利用愉快！

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

1: Unsolicited crypto, supplies by parachute, or wireless file transfer.

Click for a solution

AirDrop

Unsolicited crypto (an airdrop), supplies by parachute (an airdrop), or wireless file transfer (what it does).

2: Atmospheric schools of whales pop into the ears.

Click for a solution

AirPods

Atmospheric (air) schools of whales (pods) pop into the ears (they do).

3: Ethereal hardcopy is driverless press standard.

Click for a solution

AirPrint

Ethereal (air) hardcopy (print) is driverless press standard (what it is).

The common factor

Click for a solution

They all start with Air- and in their current releases can use wireless connections.

I look forward to your putting alternative cases.

The weather is one of precious few subjects that’s important to us all, whether we live in Alberta or Zimbabwe. It’s also notable for its extremes, that seem to be growing increasingly frequent with climate change. Over the last week or so, we’ve been through two bouts of severe weather: last weekend we had gales, then overnight into Wednesday we had unusually heavy rainfall causing local flooding. This should have been just the time to turn to Apple’s Weather app, across iPhone, iPad and Mac.

Then on Thursday, as we sat looking at the prospects for the weekend ahead, Weather alerted us to not one but two severe weather warnings from the UK Met Office, the government agency responsible for weather forecasting, and one of the leading met organisations in the world.

We then viewed the warning in the Weather app.

There was no doubt in what we saw: a “significant threat to life or property” that required us to “take action immediately”. As our kitchen features large windows on two sides, we looked out quizzically. Compared to recent days, it was fine, there was no sign of heavy cloud let alone imminent rain, and winds were light. So we went on to look at further details using the link provided. There appeared to be no such warnings in force for any part of the UK.

However, the Met Office website isn’t always as up to date as the warnings pushed out by urgent alerts. So we viewed the alert source on EUMETNET’s Meteoalarm service.

Both severe weather warnings were just a test scenario, and not intended for “operational use”. The Weather app had cried wolf.

For the rest of that day, until midnight, those two warnings continued, on our iPhones, iPad and Macs. As it was Thanksgiving, there seemed little point in trying to contact Apple, whose staff were probably more concerned with turkey than torrential downpours.

It’s only a few weeks ago that the BBC’s weather site was forecasting hurricanes throughout much of the UK as the result of a ‘data problem’. That was more obviously absurd, as the predicted windspeeds were far in excess of anything ever experienced on planet earth.

Although I have other gripes about the Weather app, they pale into insignificance compared to that day it told us that there was a “significant threat to life or property” that required us to “take action immediately”, merely because it couldn’t tell a test from a real severe weather warning.

This year has seen many people throughout the world suffer in extreme weather, with their homes washed away by floods from rain of Biblical intensity, farmland and businesses destroyed, and far too many lives lost. Never have reliable weather forecasts been more important.

This is horribly reminiscent of what happened during the Covid pandemic with contact-tracing apps. Despite unprecedented collaboration between Google and Apple, and the best efforts of teams of engineers, most of the apps that could have helped control infection with the virus were rendered ineffective by political gaming and human greed.

It happened again with the destruction of Twitter, when numerous governmental agencies were driven away by the political aspirations of one man. That turned what had been the most effective worldwide emergency alert system, warning of everything from local travel disruption to weather catastrophes, into a channel for disinformation and hatred.

One way or another, it seems that we’re increasingly incapable of using the rich technologies that have been expertly engineered for our benefit, except in the pursuit of power and profit. Maybe someone in Apple will realise the importance of its Weather app, and refocus it for its role in extreme weather events, rather than nagging us to apply sun protection on overcast summer afternoons. And please never cry wolf again.

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

1: Unsolicited crypto, supplies by parachute, or wireless file transfer.

2: Atmospheric schools of whales pop into the ears.

3: Ethereal hardcopy is driverless press standard.

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.

（Abstract）macOS 上，FileZilla 是最佳的 FTP 或 SFTP 客户端 app。

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

1: Hidden folder of indexes for a beam of light on stage.

Click for a solution

Spotlight or .Spotlight-V100

Hidden folder of indexes (the .Spotlight-V100 folder) for a beam of light on stage (a spotlight).

2: Written exam preparations conceal saved versions.

Click for a solution

Document Revisions or .DocumentRevisions-V100

Written (document) exam preparations (revisions) conceal saved versions (the hidden .DocumentRevisions-V100 folder).

3: Invisible happenings record changes to files.

Click for a solution

FSEvents or .fseventsd

Invisible (hidden) happenings (events) record changes to files (in the hidden .fseventsd folder).

The common factor

Click for a solution

Each has its own hidden folder at the top level of each regular Mac volume.

I look forward to your putting alternative cases.

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

1: Hidden folder of indexes for a beam of light on stage.

2: Written exam preparations conceal saved versions.

3: Invisible happenings record changes to files.

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 Catalina and Big Sur, macOS has started up not from a single volume, but a whole boot volume group. Among those are the System and Data volumes, intertwined by their firmlinks, a paired Recovery volume, and hidden volumes for virtual memory swap space and preboot firmware. To help macOS know which is which, each of those has a role assigned. This article explores how that works, how you can hand-craft your own Time Machine backup volume, and wonders what a Sidecar backup is.

Volume roles

Tucked away in the superblock of each APFS volume is an unsigned 16-bit integer setting that volume’s roles, chosen from 18 values ranging from None to Prelogin. Although I’m sure I’ve seen these disclosed in Disk Utility in the past, at the moment it appears the only way to read a volume’s set roles is in the command line, using the diskutil command tool, which can also create roles for a new volume, and change them for existing volumes.

The volume superblock of those that are part of a boot volume group also contains a UUID identifying that group.

Boot disk structures on Intel and Apple silicon Macs differ, as shown in the diagrams below.

That on the internal storage of Intel Macs consists of two partitions, of which only one is an APFS container.

Apple silicon Macs have three APFS containers, with their own volume groups.

According to Apple’s ageing APFS Reference, now over four years since its last update, roles found in Macs include:

• System (S), for a bootable system,
• Data (D), for mutable system components and mutable data,
• Preboot (B), for boot loader ‘firmware’,
• Recovery (R), for a Recovery system,
• VM (V), for virtual memory swap space,
• Update (E), whose purpose isn’t clear,
• XART (X), for hardware security on Apple silicon,
• Hardware (H), for firmware data in iOS, but also present on Apple silicon,
• Backup (T), for Time Machine backup stores.

There are also some that may not be encountered on Macs:

• Enterprise (Y), for enterprise-managed data in iOS,
• Installer (I), for install logs etc.,
• Sidecar (C), for Time Machine.

Finally, there are three that don’t currently have a documented character code:

• User, for Home directories,
• Prelogin, for system data used before login,
• Baseband, for radio firmware in iOS.

Using volume roles

You can view, set and change volume roles in the diskutil command tool, using its apfs command set. Although not listed now by Disk Utility, the command
diskutil apfs list [containerReference]
displays role information about every volume in the container with the given reference. Omit that option and you’ll get information for containers on all mounted disks. Passing a container reference of disk9, for example, might reveal that volume disk9s1 has a Backup role, when it’s the current Time Machine backup store.

This is potentially useful information when you’re trying to understand some of the complex structures that can occur within containers. If you follow Apple’s advice when creating multiple boot volume groups, you’ll install two or more versions of macOS within the same container. If anything goes wrong with that, then it’s essential to be able to identify which are within each boot volume group, something that should be shown clearly by diskutil apfs list.

When adding a new APFS volume to an existing container using the addVolume command, you can pass an option -role to set its role using the single characters given in the lists above, such as T for a Time Machine backup store. If that option is omitted, then no role is assigned as a default.

You can change the role of an existing APFS volume using the changeVolumeRole (or chrole) verb
diskutil apfs chrole [volumeDevice] [role]
for example,
diskutil apfs chrole disk9s1 T
to set disk9s1 to a Time Machine backup role.

This enables you to investigate how volume roles work.

Investigating backup roles

There are enormous problems in trying to perform surgery on boot volume groups, as you’re unable to pair System and Data volumes with firmlinks, or set the volume group UUID in each volume’s superblock. But there are two roles that merit further investigation, Backup and Sidecar, both apparently for use with Time Machine backup stores. I have seen it suggested that older Time Machine backups are stored on volumes with a Backup role, while newer backups are on those with Sidecar roles. So I created two test volumes, both using case-sensitive APFS, as Time Machine likes.

The Finder displayed the Backup volume using its distinctive icon for Time Machine backup stores, and Time Machine appeared happy to add it as a store, although it would need to change the volume’s permissions to set the User to read-only access.

The Sidecar volume vanished from the Finder’s normal list of mounted volumes, although it remained accessible in /Volumes, which it was shown with the regular volume icon, not that for Time Machine backup stores. That’s very different behaviour from current Time Machine backup stores. There’s another problem with the explanation given for these two roles: older Time Machine backups are made to HFS+ not APFS volumes, which don’t have volume roles at all.

Apple’s other use for the name Sidecar refers to the use of an iPad as a secondary display for a Mac, and doesn’t involve APFS volumes at all. So I’m left wondering whether Sidecar volumes are the unused remains of an old now-abandoned backup project, or the promise of something in the future.

Key point

Discover and investigate APFS volume roles using the diskutil apfs list command, passing the reference to a container, e.g. disk9, if you wish to be more specific.

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

This version adds new rules for MACOS.DUBROBBER.F2 and MACOS.DUBROBBER.H2, and modifies that for MACOS.DUBROBBER.G.

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

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

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

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

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

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

Updated 2242 GMT 19 November 2024.

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

1: Scrambled coach or underwater vessel came with the first iMac.

Click for a solution

USB

Scrambled coach (‘bus’ rearranged) or underwater vessel (‘sub’ rearranged) came with the first iMac (it was first introduced with the original iMac in 1998).

2: Burning telegraph was best with DV cameras but couldn’t compete with 1.

Click for a solution

FireWire

Burning (fire) telegraph (wire) was best with DV cameras (it was standard with most of them) but couldn’t compete with 1 (Macs abandoned it in favour of USB and Thunderbolt).

3: Could sound seedy or sexy, so it was terminated by 2000.

Click for a solution

SCSI

Could sound seedy (it’s pronounced the same as the word ‘scuzzy’) or sexy (it had originally been intended to be pronounced like that), so it was terminated (one of the bugbears with SCSI is using its special bus terminators) by 2000 (Apple discontinued support in 1999).

The common factor

Click for a solution

In their day, they were each high-speed external interfaces for Macs.

I look forward to your putting alternative cases.

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

1: Scrambled coach or underwater vessel came with the first iMac.

2: Burning telegraph was best with DV cameras but couldn’t compete with 1.

3: Could sound seedy or sexy, so it was terminated by 2000.

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.

If you’ve already got a new M4 Mac and tried to run a macOS virtual machine on it, then you might have been disappointed. It seems that M4 chips can’t virtualise any version of macOS before 13.4 Ventura. So before you trade in or pass on your M1, M2 or M3 Mac, if you need access to older VMs, you might like to check whether this affects you.

I’m indebted to Csaba Fitzl for drawing my attention to this problem, and for reporting it to Apple in Feedback FB15774587. It has also been reported as affecting UTM, and I believe affects all other macOS virtualisation software for Apple silicon.

The bug

Running a macOS VM for any version before 13.4 Ventura on an M4 Mac results in a black screen, and the VM fails to boot. This is true whatever settings are used in the virtualiser, even if it’s set to boot the VM in Recovery mode. It’s also true when that VM has been built on that Mac: although that appears to complete successfully, when first run that VM opens as a black screen and never proceeds with personalisation and setup.

Currently the only way to run a VM with macOS prior to 13.4 Ventura is to do so on a host with an M1, M2 or M3 chip.

Can this be fixed?

Unfortunately, as this bug prevents the VM from booting, there’s no reliable way to access its log to discover what’s going wrong there. There’s no sign of the failure in the host’s log either: the host appears to initialise its Virtio and other support normally, without errors or faults. After those, virtualisation processes on the host fall silent as they wait for the VM to start, which never happens.

There is a useful clue in Activity Monitor, though: in its CPU pane, despite being allocated multiple virtual cores, only one is seen to be active on the host. That implies the failure is occurring before the VM kernel boots the other cores, an event that occurs early during the kernel boot phase. Until that point, pre-boot phases and the kernel run on just a single CPU core.

macOS 13.4 updated iBoot to version 8422.121.1, so at first sight the VM could be failing when running older firmware. That doesn’t appear likely, as version 8422.121.1 was also installed in the 12.6.6 security update, so 12.7.x shouldn’t suffer this problem, but it does.

It thus appears most likely that this bug strikes in the early part of kernel boot, in which case the most feasible solution would be to fix the bug in macOS kernels prior to 13.4, and promulgate new IPSW image files for those. I suspect that’s very unlikely to happen, and as far as I’m aware it would be the first time that Apple has issued revised IPSWs.

Which macOS can you virtualise?

Support for lightweight virtualisation of macOS on Apple silicon Macs was still in progress in the first version of macOS to run on M1 chips, Big Sur. You therefore cannot create or run Big Sur VMs.

The first versions that can run in VMs are macOS 12 Monterey, although prior to 12.4 they can sometimes be a bit fractious. They also have major limitations, such as not supporting shared folders with the host.

This is 12.1 with its old System Preferences, running happily on an M3 Pro.

macOS Ventura should run well on M1, M2 and M3 hosts, and 13.4 and later on M4 hosts too.

macOS Sonoma should run even better on all current Apple silicon Macs, and delivers a much improved display with autoscaling. However, 14.2 and 14.2.1 don’t automatically support shared folders because of a bug that was fixed in 14.3.

macOS Sequoia is fully compatible, and adds support for iCloud Drive and some other Apple Account features, although still won’t run App Store apps. It may also fail to install the required extras to support Apple Intelligence.

Summary

• Currently, M4 Macs can only run VMs of macOS Ventura 13.4 and later, 14 Sonoma, and 15 Sequoia.
• M1, M2 and M3 Macs can run VMs of macOS Monterey 12.0.1 and later.
• macOS Big Sur 11 can’t be virtualised on Apple silicon.

Further information

Viable and virtualisation
Why macOS 14.2 & 14.2.1 VMs lose shared folders, and how to work around it

Postscript

I’m grateful for the suggestion that it might be possible to work around this problem by running the older VM on a single core. Although I did manage to do that on an M3 (the first time I have seen recent macOS running on just one core!), that fails just the same on an M4, I’m afraid.

（Abstract）终于不用再搞“先放大再缩小”这种傻操作了。