© Tierney L. Cross/The New York Times
For those working with Rich Text without embedded images, my free editor DelightEd offers a suite of unique features. I wrote it when macOS Mojave introduced Dark appearance mode, with the primary purpose of composing Rich Text documents that work independent of appearance. For that it can set styled text on a background that ensures perfect readability in both Light and Dark modes.
Since then it has gained other unique features, including support for creating interlinear text, in which different translations or versions of the same document are interleaved line by line. It will also open PDF documents and automatically extract all their text content.
General features supported include Writing Tools (Apple silicon Macs), case transformations, and a full suite of substitutions. However, until this new version of DelightEd, substitution settings haven’t been saved in DelightEd’s app settings. Version 2.5 now puts that right: to set the app’s default substitutions, set them up using the Substitution command in its Edit menu, for instance enabling Smart Links.
Then save those to its settings using the Save Defaults command in the app’s menu. Each time you open DelightEd after that, its substitutions will start from those saved defaults.
DelightEd version 2.5 for macOS 11.5 Big Sur and later, including Tahoe, is now available from here: delighted25
from Downloads above, from its Product Page, and through its auto-update mechanism.
I’m very grateful to Manuel for asking for this to be fixed.
© Robert F. Bukaty/Associated Press; Sophie Park for The New York Times
© Mussa Qawasma/Reuters
Many discovered how long 5 minutes could last when they updated from macOS 26.3.1 to 26.4. Right at the end of its Preparation phase, Software Update showed there were only 5 minutes remaining for far longer. This article reveals what went wrong with that update.
My observations come from a Mac mini M4 Pro running a vanilla installation of macOS Tahoe, being updated from 26.3.1 (a) with the BSI installed, to 26.4. Times and details are taken from log extracts covering the final 14 minutes of the update, immediately prior to the reboot for its installation.
At almost exactly 18:43:00, softwareupdated reported that the PREPARING_UPDATE phase was in progress, with 70% complete on the progress bar, and 20 minutes remaining. Periodic preparation activities were then reported in the log, mainly verifying components to be installed as part of the update. One of the longest of those, /usr/standalone/i386/Firmware.scap, took nearly 6.5 minutes alone, although you might wonder why that’s required on an Apple silicon Mac!
Eleven seconds later, softwareupdated changed the progress bar to display 10 minutes remaining, with 71% completed. Just 1.5 seconds later that changed again to display 5 minutes remaining with 94% complete. Six seconds after that, with 5 minutes still displayed, the log records 98.6% was complete.
The log and progress bar then remained stuck at 5 minutes remaining and 98.6% complete for the next 11 minutes and 47 seconds, before changing to 99.9% complete and no time remaining.
These are plotted in the chart below.
The final 5 minute period started at 18:43:12, and lasted until 18:55:04, as reflected in the long period of 98.6% completion (upper line) and 5 minutes remaining (lower line).
The “5 minutes” remaining actually took 12 minutes and 7 seconds, although log entries make it clear that preparation continued throughout that time, with further verifications and “Preparing system volume…”. Those details were reported as ActionText for progress monitoring, but curiously aren’t accessible to the user at the time.
Log entries record softwareupdated keeping detailed records of progress over this period, though. For example:18:51:32.924688 softwareupdated PrepareUpdate PROGRESS (Continue) | state:{
ActionText = "Preparing system volume...";
ElapsedTime = 490;
ExpectedTime = 1335505;
PercentBytesComplete = "48.05373989419242";
PercentComplete = "4.701870471432042";
}
But those aren’t reflected in the progress bar.
Once the update had completed that preparation phase, extensive checks were performed to ensure it was correctly configured, and components were moved into place in the ‘stash’ to be used during installation. One second after successful completion, softwareupdated locked the controller state and waited for the reboot to start installation. Rebooting followed less than two minutes later.
The macOS 26.4 update for Apple silicon Macs was large, and the work required to verify its contents and complete its preparation was incorrectly reported in both percent completion and time remaining. Even in smaller updates, some form of progress needs to be shown in the progress bar during these later stages of preparation, or users may be mislead into thinking the update has frozen or failed, and could for example restart their Mac to try updating again.
When an update claims there’s only 5 minutes left, that could readily extend to longer, possibly on slower Macs as long as 30 minutes or more. Unless there’s evidence that the update has gone wrong at this stage, you should leave your Mac to complete it, as it almost certainly will. If you’re still in doubt and want to confirm that the update hasn’t frozen, open Activity Monitor and look for around 100% CPU from softwareupdated or related processes, and disk activity.
Unfortunately, there’s nothing the user can do to accelerate macOS updates.
One of the longstanding jokes in computing is how misleading progress indicators can be, and last week most of us had a timely reminder when we updated macOS. However much we might like a perfectly accurate linear indicator for macOS updates, this is one of those situations where the best we can expect is a compromise, as I tried to explain here.
There are two types of progress indicator, determinate and indeterminate, depending on whether the task is quantifiable and progress is measurable. Determinate indicators are always preferred, as they inform the user whether they need only wait only a few moments, or they have time to enjoy a leisurely meal, but that requires quantifiability and measurability.
The simple example is copying a file from one disk to another: although macOS doesn’t know in advance how long that might take, it can quantify the task as the size of the file to be copied, then keep track of how much of that has already been completed. When half the size of the file has been copied, the progress bar can be set to half-way along its total length, so providing an accurate indication of progress.
However, with some copy operations that breaks down: when copying a sparse file between APFS volumes, for example, only the sparse data is copied, not the whole file size. As a result, copying sparse files often results in progress bars that jump from a low point to completion in the twinkling of an eye. This also relies on the quantities involved being linearly proportional to the time required, an assumption that often breaks down when downloading from a remote server.
Updating macOS consists of a series of many tasks (see references at the end), of which only one, downloading, is both quantifiable and has measurable progress, and even that may be far from linear. Apple therefore has a choice of:
As downloading is the one task that is quantifiable and its progress is measurable, I’ll start there.
For this, the progress bar starts an an arbitrary 15%, and softwareupdated assumes the total size of that download is the magnitude of that task.
When the download has been completed, the progress bar reaches an arbitrary 55%, and its caption then changes to reporting progress with preparation.
There is a weakness in the assumption that becomes obvious when downloading from a local Content Caching server, as the final 1 GB or so normally isn’t provided from the cache, but has to be freshly downloaded from Apple’s servers. However, that isn’t normally apparent when caching isn’t available and the whole of the download comes from the same remote source.
For the remainder of the progress bar, between 0%-15% and 55%-100%, the task is neither quantifiable nor measurable. Instead, softwareupdated divides it into a series of subtasks, each of which has a fixed progress level. One list of subtasks and levels obtained from the log is given in the Appendix at the end.
The disadvantage of that strategy is that time required by each subtask varies with the update and the Mac being updated. Inevitably, computationally intensive subtasks will proceed more rapidly on newer and faster Macs, while those mainly constrained by disk speed should be more uniform. Large updates should take significantly longer, and that will vary by subtask as well.
A particular problem with some more recent macOS updates, including that from 26.3.1 to 26.4 last week, has been unmarked progress over the final “5 minutes” of preparation. While indeterminate progress indicators continue to move over that period, and reassure the user that the task hasn’t ground to a halt or frozen, the progress bar shown had no intermediate points, making it easy to misinterpret as failure to progress. If this is going to be a feature of future macOS updates, Apple needs to insert some intermediate points to let the user know that the update is still proceeding.
A progress bar that combines different measures of progress, such as download size and substages, can work well, but only if the user is aware of how to read it. As we only update macOS a few times each year, that isn’t sufficient exposure, and how it works needs to be made explicit.
How macOS 26 Tahoe updates 1
How macOS 26 Tahoe updates: 2 Finite state machines
How macOS 26 Tahoe updates: 3 Catalogues and preparing to download
How macOS 26 Tahoe updates: 4 Download, preparation and installation
Read the macOS update progress bar
Progress bar percentages set for some subtasks during updating macOS 26.2 to 26.3 on an Apple silicon Mac:
Note the majority of the progress period (79%) is assigned to downloading (15%-55%) and preparing (60%-99%).
In my account of how Tahoe updates macOS, I had reached the stage when Rosetta and the main update had started downloading from Pallas, Apple’s software update server (see the Appendix at the end for further explanation of terms used).
Currently, the main update download (at least) is compressed using Zip, and is decompressed as a stream during download, so there’s no delay decompressing during the preparation phase later.
In this case, downloading the main update was completed within 8 minutes. The source of the Zip archive was originally given as a path on [https://]updates.cdn-apple.com/2026WinterFCS/patches, and that was written to a local path on /System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/ In my case, though, I have a local Content Caching Server running, and immediately before the download started com.apple.AssetCacheServices substituted a download URL on that server to ensure the update was obtained through the local caching server. At the same time, an Event Report was sent back to Apple, recording the start of download.
Progress was updated every second during the download, and brought the progress bar from 16% to 53.9% over the following 8 minutes, with little other activity taking place.
Activity then changed to what is repeatedly referred to as Preflight FDR Recovery, and is the first entry point for the UpdateBrainService, downloaded for MobileSoftwareUpdate rather than softwareupdated.
This runs an Event Recorder and begins to perform preflight checks to “recover FDR SFR”, and to perform a “firmware-only update”. To prepare for that, it retrieves various nonces and their digests for LocalPolicy, RecoveryOS boot policy, and others. Following those is the first of many attempts to determine purgeable space, in preparation for installation of the update. Those are performed by com.apple.cache_delete.
Pallas was then checked to see if there was any more recent version of RecoveryOS UpdateBrain, but there wasn’t. A further check for any newer recoveryOS was also made, before the main macOS update was prepared, at a progress level of 60% as set previously.
The first step of the main preparation phase is to purge staged assets with com.apple.cache_delete. With that complete, UpdateBrainService recalculates cryptex size requirement for the update, and the install target prepare size:
UpdateBrainService then checks volume free sizes, and confirms that they’re sufficient to complete the update. It next creates a ‘stash’, which is protected by keys in the stash keybag, handled by the Secure Enclave Processor. There is then another round of purging with com.apple.cache_delete.
Much of the preparation phase is spent verifying the protection of installation packages, cryptexes, then the contents of /System/Applications and /System/Library. As progress is about 64% complete, System volume preparations are started, and there’s another round of purging by com.apple.cache_delete. There’s surprisingly little log activity as progress passes 70% complete.
With progress reaching 84% complete, UpdateBrainService starts unarchiving files in parallel, taking just under 5 seconds to complete those. Following that, there’s another brief period unarchiving data files in parallel, then working with the contents of /System/Volumes/Update/mnt1/private/var/MobileAsset/PreinstalledAssetsV2 as progress reaches 87% complete.
When there’s 87.5% completed, UpdateBrainService reports it’s creating hard links in parallel, then is searching for new paths and verifying files, such as those in the Ruby framework. The Recovery volume is unmounted, and there’s yet another purge with com.apple.cache_delete. After those, key volume locations are checked.
The high water mark of disk usage during update is prepared. This reveals some of the steps to be undertaken during installation, including:
There’s a further round of purging with cache_delete before declaring PrepareUpdate as successful, then suspending the update briefly. When update resumes, the Update volume is mounted and prepared, and there’s another round of purging. The System volume is then mounted, checked, and prepared. Progress is now at 98.5% complete, and once 100% is reached, the countdown to restarting the Mac is begun.
During the download and preparation phases, apart from repeated purging, the log is generally quiet. This changes dramatically once the Mac starts preparing for shutdown and installation. WebKit is cleaned up and shut down, as are many other processes. The ‘stash’ of update components is then committed, and final scans and checks are completed.
The update is then applied, followed by Rosetta, RecoveryOS, UpdateBrain and finally minor documentation. After that period of nearly 20 seconds, this phase is declared complete, and a restart is notified before waiting for the essential reboot.
Once rebooting by root has been initiated, the boot chime is muted to ensure the update continues in silence. The last log message is written a few seconds later, and UpdateBrain then runs the update.
Less than 3 minutes later, the system boot is recorded in the log, and kprintf is initialised 5 seconds later. About 3 minutes afterwards softwareupdated is started up, and runs various clean-up routines to complete the update sequence in conjunction with ControllerSetup and a Finite State Machine.
How macOS 26 Tahoe updates 1
How macOS 26 Tahoe updates: 2 Finite state machines
How macOS 26 Tahoe updates: 3 Catalogues and preparing to download
Following a general outline of what happens during a macOS 26 update, and a more detailed account of how it uses finite state machines and sends progress reports to Apple, this article describes what happens before Software Update downloads the main update. This was started by opening Software Update in System Settings of macOS 26.2 when the update to 26.3 was available, on a Mac mini M4 Pro. The Appendix at the end explains several in-house jargon terms used widely through these log entries.
In this case, checking for an update was instigated by opening Software Update in System Settings. That initiated a series of preliminary checks to:
A new scan for updates is started, with a UUID chosen to identify it. The UUID used is version 5, so is expected to be based on a hash of other identifiers, and is unique to this software update. The catalogue is downloaded from Pallas, and analysed for new versions being offered for download.
In this case there are two available:
Both of those use the Zip compression algorithm, and are designated as being ZipStreamable. macOS263Short is clearly the Delta update from 26.2, whose download size was then displayed in the Software Update panel. macOS263Long appears to be a full upgrade, equivalent to the macOS Installer app in terms of its contents.
A similar sequence of events occurs when you request a list of available macOS installers using the commandsoftwareupdate --list-full-installers
The following checks are repeated at frequent intervals throughout scanning and preparation:
Early estimates are made of the size required to prepare and apply the update. Prepare size consists of:
These total 11,595 MB when first calculated, but a little later the snapshot installation size was increased to 5,154, for a total of 12,963 MB.
The apply and reserve size consists of twice the update partition size plus the update APFS reserve of 700 MB, plus 231 MiB for volume sealing overhead, giving a total of 931 MB. Presumably any shortfall in free space available would be notified to the user at this stage, and the update cancelled.
The policy for updates is determined in detail, before Pallas is asked for a catalogue of MacSplatSoftwareUpdate, updates using cryptexes, probably including both older RSRs and their successor BSIs. In this case, that catalogue is empty.
softwareupdated then takes a back seat for much of the following 15 seconds or so, as mobileassetd determines which mobile assets need to be updated. These are the multitude of components to support Siri, AI and other features. This too is run by a finite state machine, AutoControlManager, which downloads catalogues of these components to assemble its auto-stager. One catalogue alone lists 91 available for update, but thankfully many of those don’t need to be updated.
Once that’s complete, the progress bar is displayed and updated by softwareupdated.
This is divided into zones used for different stages of progress by softwareupdated. These can be summarised as:
During the downloading and preparing stages, progress updates are made according to the amount of the stage that has been completed. Otherwise they are made when each stage has been achieved.
In practice, progress is most meaningful during the downloading and preparing stages, between percentages of 15-55 and 60-100. Time estimates are displayed for both of those separately, with download time remaining based on size transferred. Once downloading is complete, the final 40% of the bar is given a fixed period of 30 minutes to complete, although that’s never required now.
softwareupdated determines and downloads the cryptex updates, any SFR software update, any Rosetta update, any RecoveryOS update and the RecoveryOS update ‘brain’ for that. These are set up with their own finite state machine that downloads the catalogue, determines what should be downloaded, and downloads it. The final phase handles the documentation for the update, in this case consisting of
There’s an irony here that the first two are so tiny by comparison with the last.
In this case, downloading the update was completed within 10 minutes of obtaining the first update catalogue from Pallas.
Login
mobileassetd determines a potentially long list of mobile assets to be updated.
「我怀念那些互联网上图片总是准确的时代……等等，好像从来没有过这样的时期。」
最近伊朗冲突的消息开始在各大信息流里疯狂刷屏，爆炸、防空警报，各种冲击力极强的画面，但这里面让无数人点赞、转发的「战地纪实」，竟然有一大半都是假的。
▲浏览量都超过百万次，但是最后都被证实是 AI 生成的视频
在 X 上多个认证的自媒体，发布了数条由 AI 生成的假视频；最后却在补充信息都提到，视频内有非常明显的 AI 迹象，例如烟雾的效果，还有变形的水面和屋顶的太阳能电池板。
这些视频有的来自 9 年前毫不相干的旧冲突，有的是被 AI 操纵的合成幻影。最为荒诞的还是，美国德州州长 Greg Abbott 也转发了一段电子游戏视频，随后迅速将其删除。
▲A电子游戏的模拟画面，该视频帖子已经有超过 700 万次浏览｜视频来源：X@realJoelFischer
这条在海外社交媒体上被广泛引用的所谓「第一手冲突录像」，竟然是直接截取自军事题材电子游戏。
不仅把 AI 当新闻，把游戏画面当新闻看，十分令人感慨。在这个 AI 生图生视频狂飙突进的 2026 年，「有图有真相」这句古老的互联网格言，已经沦为一句彻头彻尾的笑话。
而这些百万次转发的内容，也都被证实是个超低级 AI 缝合怪。
除了视频的泛滥，引起大家关注的还有一张在 X 上疯传的卫星图。毕竟，谁会花几个亿发颗卫星，就为了在网上 P 张图骗我？
图片显示，位于卡塔尔的一个美军雷达系统，在遭受伊朗无人机打击后化为废墟。连伊朗的主流媒体《德黑兰时报》官方账号都迫不及待地转发了这张「战果图」。
▲图片来源：X@TehranTimes79
短短 48 小时内，这条帖子的阅读量直接突破了 100 万。但很快，开源情报专家们就把这张图的底裤扒光了。
经过比对，这根本不是什么卡塔尔的雷达基地，而是巴林的一个区域。更荒谬的是，这图是用一张一年前的老照片强行用 AI 「捏」出来的。
怎么看出来的？有网友发现这张图片细看非常拙劣，虽然建筑看起来被炸毁了，但周围停放的车辆位置竟然和一年前一模一样；更离谱的是，所谓「爆炸后」的光照阴影角度，跟一年前那张晴朗日子的图分毫不差。
尽管目前大多数的 AI 生成内容，都被强制要求带上显示水印或者数字水印，但这套方案还是容易被绕过。
就拿 Nano Banana 生成的图片来说，官方提示会加入 Gemini 的 Logo 水印，和无法被肉眼察觉的 Synth ID 数字水印，但在社交媒体上，经过多轮的手动截图裁剪压缩等操作，Gemini 就很难再识别到之前嵌入的水印。
▲在 reddit 上已经有相关绕过 Synth ID 水印的方法
1、抓细节，看不对劲的地方
有人问，既然最后都发现那些 AI 视频和图片破绽这么明显，为什么大家一开始没看出来？
理由其实很简单，当我们看一张 AI 生成的人脸时，我们的大脑会本能地寻找违和感，眼睛、皮肤纹理、耳朵的形状，这是我们几百万年进化出来的生物本能。
但是，当俯视一张从几百公里高空拍下来的建筑、道路和地形时，这种本能失效了。因为没有人天生知道，在特定分辨率的传感器下，一座炸毁的雷达站「应该」长什么样。
没有太多可以参考的信息，AI 捏造的这些陌生内容，自然而然地就容易变成我们普通人眼里的客观事实。
在算法已经能完美模拟光影和肌肤纹理的今天，寻找破绽的逻辑已经变了。除了要打破这种需要依赖参考系的想法，找各种技术上的 Bug，更多地是去寻找现实的逻辑断层。
例如，背景里不合时宜的建筑风格、人物违背常理的微小动作等。
▲未经查证的照片
在前段时间马杜罗被捕后，社交媒体上也疯传了几张他的「囚禁照」，外媒的视觉调查团队迅速发现，这些图片存在可疑之处，飞机窗户的设计与现实机型不符、马杜罗衣服在两张照片里不同。
虽然没有直接证据证明它们是假的，但这些疑点，也让媒体决定不刊登这些照片。
2、谁发的信息，比信息本身更重要
一张图片背后，发布者的身份往往比内容本身更能说明问题。
这张所谓的哈梅内伊遇害的照片，也在社交媒体上获得了 550 万次的浏览，但这个账号的主人，在这里的网页关于部分写着，「SilverTrade.com 致力于提供贵金属行业最准确、最具洞察力和最及时的报道。」
还有马杜罗那张照片，即便是在 Truth Social 上发布，但多个新闻机构依然对图片的真实性心存疑虑。
最后，大多数的媒体是选择了以截图形式引用了整条帖子，而非单独呈现这张照片，很有一种「不信任但有新闻价值」的处理方式。
3、追踪数字足迹，历史记录不会说谎
AI 制造的假新闻，最常见的手法是「挪用」旧素材。通过 Google、TinEye 等搜索引擎的反向图片搜索，甚至查看图片元数据（比如拍摄时间、设备型号），就能快速判断内容是否造假。
▲https://tineye.com/
例如这张经典的篡改图片，只是在一张已有照片的前提下，通过传统的复制移动手段，就轻松骗过了一众媒体。
4、从时间和地点，验证关键背景信息
假设我们看到一段声称拍摄于某地的视频，我们可以通过 Google Maps 或卫星图像检查画面是否与该地点一致。
▲Google Earth 会提供完整的历史图像和街景
还可以用 SunCalc，通过画面里的阴影方向，推算出拍摄的大概时间。如果声称是昨晚拍的，但阴影显示是正午，基本可以判定造假。
▲ 在摄影圈，SunCalc 也是一个精准计算太阳和月亮方位，找到拍摄黄金时刻的地理网站
5、善用深度研究，让 AI 对抗 AI
现在几乎所有的 AI 工具都有自己的深度研究功能，像是之前我们总结的春节 AI 大战内容，让 ChatGPT 的深度研究，先跑上半个小时，为我们总结了这些信息。
深度研究的好处在于，AI 生成的每一句话都附有来源链接，你可以直接看到信息出自哪里、属于什么性质。如果我们对数据精确度要求较高，还可以在提示词里加上：「对每一个结论，给出一个可信度判断。」
但要注意一点：深度研究可能靠谱，普通问答不太行。
直接问 AI「这条新闻是真的吗」，它有时候会把社交媒体上某人随口发的推测，和正规报道混为一谈，给我们一个「看起来有理有据」的错误答案。深度研究至少让你能看到原始信息源，自己判断。
▲这两张图，你能分出哪张是真实的吗
例如，当我们把这两张图片直接丢给 AI，问「这张图片是由 AI 生成的吗？」
Gemini 说这两张图都极有可能是基于同一张原图，进行了后期图像处理或 AI 换色生成的产物。而 ChatGPT 和豆包告诉我，那张红色的图片更大概率是 AI 生成的。
专门的图片篡改监测工具现在也有很多，有网友前几天还专门测试了一波市面上的十多款 AI 内容检测工具（包括 hivedetect.ai、aiornot.com、copyleaks.com、以及部分通用 AI 工具），结果超过 1000 次的测试显示，
魔法打败不了魔法，用 AI 检测 AI 是一场注定破产的幻想。
▲图片来源：NYT 文章（These Tools Say They Can Spot A.I. Fakes. Do They Really Work? 这些工具声称可以识别人工智能造假。它们真的有效吗？）
AI 检测工具可以作为参考，它能给我们一个方向，但无法直接做判断。
Adobe 在 PS 25 周年的时候，还推出过一个图片真假小测验的网站，感兴趣的朋友可以去看看，当时的技术只能是纯 PS，就已经能做到有些图片难以辨别，更不用说现在强大的 AI。
▲ 分辨图片是 PS 还是真实的：https://landing.adobe.com/en/na/products/creative-cloud/69308-real-or-photoshop/index.html
面对最近各种 AI 假图片、假新闻的泛滥，社交平台也开始了行动。
从今天起，X 平台上的创作者如果上传 AI 生成的相关视频却未标注「这是 AI 制作」的，将被暂停 90 天的「创作者收入共享计划」。如果再次违规，永远无法从平台赚到广告分成。
X 的平台分成向来可观，不少 AI 自媒体都有在 X 同步更新；年初 X 平台还更新内容激励计划，以首页出现的次数来对内容进行收入划分，同时鼓励长文的创作。
▲X 产品负责人 Nikita Bier 发文称修改创作者收益分成
这条政策一出，X 上的创作者和网友们都炸开了锅。有些人支持，「总算要管管了！」但也有人质疑，「为什么只针对冲突视频？其他领域的假内容不一样造成各种危害吗？」
我想即便这些措施涵盖了各个领域的假消息，实际的成效恐怕也并不乐观。毕竟，用户可以轻松地使用其他账户重新发布，而平台的内容审核，远远赶不上假图传播的速度。
在 The Verge 采访虚假新闻专家的文章里面提到，「普通人必须清醒地认识到，当前的数字环境，天然就是向操纵和欺骗倾斜的。」
现在看来更大的问题还是回到了，我们对 AI 伪造的警惕性仍然不足。但作为一个吃瓜群众，如果要自己对每一条新闻都要去做事实核查也太麻烦了。
保持耐心或许是更简单的方法，姜文电影里那句「让子弹飞一会儿」，会是我们在算法操纵下，最清醒的一种特立独行。
#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。
Script-based updaters were underpowered and too unreliable to build the Signed System Volume and other components of macOS in Big Sur and beyond. When Apple was designing the software update subsystem to be used for its new Macs, it chose to develop a modern design from scratch, built around finite state machines. The end result is seen today in the log entries made when updating macOS.
At first sight those appear to be examples of everything the Unified log shouldn’t be. From the initial entries reporting the softwareupdated service is checking for updates, there’s a succession of huge and apparently incomprehensible entries in the log that surely belong somewhere else. In fact we’re given a remarkable step-by-step account of some of the most elegant and successful engineering design in macOS that reveals its inner workings. It also shows how Apple is now able to detect and fix update problems in real-time.
This is a formal model used widely in computing to design, describe and implement a machine or automaton that can only exist in one of a finite number of states. Its state changes in response to defined events, which result in actions that in turn determine its transition to its next state. Although some FSMs are non-deterministic and subject to chance, those in softwareupdated are governed by deterministic rules. This is illustrated in the excerpt below, extracted from a sequence of log entries for one of the FSMs run by softwareupdated when it’s working out what updates are required, early during macOS updating.
This FSM starts here in the top state shown in blue, where it’s scanning for an SFR update. If that’s successful (the event), its next action is to decide whether the update requires an update to Rosetta 2. If it does (the next event), then its action is to scan for Rosetta updates, and it then transitions to its next state of scanning for Rosetta. If that’s followed by the event that the scan succeeds, the next action is to decide whether an update to RecoveryOS is required, and so the FSM proceeds to work out what updates are required before starting to download and prepare them for installation.
This may appear long-winded, but FSMs can be described formally and from there implemented in code that is robust and correct, fundamental requirements for macOS updates. It also builds in flexibility to tailor each update to what that Mac requires.
The unified log is used by softwareupdated to document the operation of the several FSMs it runs. If an error occurs during software update, this enables its origin and causation to be established, one of the primary purposes of the log. Full detail has to be captured in entries at the time the FSM is running, as they can’t be recreated in retrospect.
As a result, every state transition, each event, and all actions are entered in full detail. The message field in those log entries identifies the FSM involved, reports its current state (S), the event (E), its action (A), and then provides full information about its current data. Those must enable the FSM to be recreated and run in the event that something goes wrong, to investigate and fix malfunction or failure.
Although those large and copious log entries are a challenge to browse, the architecture of the Unified log is designed to cope with them. Such long messages are stored separately in the warren of directories inside /var/db/uuidtext, and don’t burden the main log’s tracev3 log files.
When softwareupdated checks for, discovers, downloads and prepares the macOS update from 26.2 to 26.3, the following named FSMs are identifiable in log entries:
in the order in which they appear. In some cases, before the FSM is run, it’s loaded with Events that are detailed in the log, and provide further insight into what that FSM does.
The UUID used for FSMs and throughout softwareupdated is allocated at the start of these processes, before scanning for software updates. It’s referred to as “the SUCore SoftwareUpdate UUID”, and doesn’t appear to be the same as well-known UUIDs used elsewhere. However, as it’s a version 5 UUID it probably doesn’t contain any randomly generated content. This is worth bearing in mind, as it’s this UUID that is attached to Event Reports.
Many of us can recall macOS updates that have gone badly wrong, and some that had to be withdrawn or replaced because of their problems. Apple tackles that now using an event reporting system that provides real-time information about how every Mac being updated is progressing. This is anonymised, the only identifier being the UUID allocated to that software update by softwareupdated before starting to scan for updates.
At frequent stages during software update, softwareupdated updates its Event Report to reflect progress, and that’s automatically uploaded to Apple’s servers at an HTTPS address starting with xp.apple.com/report/ Although typically only just over 500 bytes in length, a typical Event Report contains the following named fields:
UUID, audienceType, batteryIsCharging, batteryLevel, currentBaseOSVersion, currentOSType, currentOSVersion, currentProductVersionExtra, dataFsCapacity, dataFsFree, deviceClass, deviceModel, event, eventTime, lowPowerMode, macPlatform, mandatoryUpdateEligible, mandatoryUpdateOptional, preSUStagingEnabled, preSUStagingMaxSize, preSUStagingOptionalSize, preSUStagingRequiredSize, preferredType, rampEnabled, rapidSecurityResponseCombo, rapidSecurityResponseInstalled, rapidSecurityResponseSemiSplat, reportVersion, result, storageCapacity, ucoreVersion, systemFsCapacity, systemFsFree, targetOSVersion, totalRequiredFreeSpace, updateType.
Most should be fairly self-explanatory, and in this case the event field was set to SUCoreOTAPreSUStagingDetermineStarted.
The first of these is sent less than one second after starting to scan for updates, when policy and sizing for the updates to be downloaded have just been determined, and that’s repeated after each significant stage until the Mac is rebooted to apply the update. I suspect there’s also a final Event Report sent once the Mac has booted into the updated macOS.
Apple is thus able to track progress for each UUID during the software update process. Should it detect a problem, for example a required component being unavailable, it should be able to take immediate action to address that, rather than having to wait for individual users to report errors or failures long after they occurred.
sysdiagnose.Although the way that macOS updates itself has changed beyond all recognition over the last few years, we tend to assume that it still works much as it did in the past, downloading a single update file, decompressing and installing that. This series of articles takes a deeper dive into what actually happens, and tries to explain how it differs from previous package updates.
This account is primarily based on a detailed analysis of log entries obtained from updating 26.2 to 26.3 on a Mac mini M4 Pro, supported by additional information obtained from updating virtual machines to 26.3. macOS updates have changed considerably even since Big Sur, but I believe that their mechanisms have remained more similar than they differ from those before.
One of the most basic and striking observations about macOS updates is their variation in size. Although those reported on many Apple silicon Macs making the same single-step update are similar, some are considerably greater. As updates aren’t offered in standalone form, and are only provided via Software Update or its command line equivalent softwareupdate, the only practical way to assess this is to update a range of virtual machines.
Software Update also reports two update sizes to the user: the first is given as a promise prior to the user initiating the update, the other displayed above the progress bar during downloading, in the progress window. A third figure can also be derived by obtaining the update through a local Content Caching Server. Results obtained for the update to 26.3 are shown in the table below.
When originally performed on the host Mac, the initial claimed and reported download sizes were both smaller at 3.68 GB.
Although sizes for the update from 26.1 to 26.3 are surprisingly slightly less than those from 26.2, these demonstrate that the greater the difference between the original and destination versions, the larger will be the size of the download, as expected. However, there is no evidence that any of these shared the same download size: each is different, as if tailored to the requirements for the original macOS. This is very different from a system offering three types of installer for Delta and Combo updates, and a whole-system Installer for upgrades from an earlier major version.
Prior to the update being applied, its download and preparation is largely controlled by softwareupdated and its associates. Before any downloading is initiated, that calculates the disk space required to download and prepare each of the components required for the update, a task it refers to as CalculatePrepareSize. This is critical if the update is to ensure that it won’t run out of free space during the update, and is checked repeatedly during the downloading sequence, as individual components are prepared for installation.
CalculatePrepareSize calculates the following values:
For any given version of macOS (ignoring RSRs and BSIs that may later replace them), each hardware architecture is thought to have its own pair of cryptexes, and they aren’t thought to differ between Macs of the same architecture. Thus, no matter which their original version of macOS, all Apple silicon Macs updating to macOS 26.3 should be provided with the same app and system cryptexes, of the same sizes.
Sizes for snapshot update and installation clearly differ according to the original version of macOS. Although almost self-evident, it’s important to remember that updating macOS from a previous major version will normally require greater free disk space than updating by a single minor or patch version.
Given the sizes above, it’s also obvious that components downloaded for macOS updates are compressed to substantially smaller sizes, so have to be decompressed on the Mac being updated. Thus, the download sizes reported to the user are far smaller than the free disk space required to prepare and install the update.
The overall sequence of stages is:
softwareupdated tries to connect to Apple’s software update service to check whether there’s an update available for that Mac. Checks can also be initiated manually, or by apps like SilentKnight. If an update is found, the Mac and its current system are checked to determine whether it meets the requirements for that update.softwareupdated to indicate to the user how far update download and preparation have progressed.Because stage 11, applying the update, is run by the update brain, normal logging doesn’t take place, and no clear account can be made of what happens then.
From Big Sur onwards, the great majority of this is performed in what is effectively a single thread run on CPU Performance cores. This is readily seen when updating a virtual machine, for example. It’s thought that updates are constrained to use the equivalent of just a single P core to enable the user to continue working through a process that could take up to an hour. Thankfully, with the advent of faster models and continued engineering optimisations, this Mac mini took just 18 minutes from requesting the update to 26.3 until it was logged into and fully functional again.
In subsequent articles I will look in more detail at the stages listed above.
Conclusions
This weekend we’re escaping from the chills of February to travel to Capri, off the coast of southern Italy. From the north coast of this island you can look across the Bay of Naples towards the crowded city to the north. It’s a small island, with two little towns: Capri in the east, spilling down to harbours on the north and south coasts, and Anacapri, nestling in the hills to the west.
It’s ruggedly hilly, with spectacular coastal scenery of high sea cliffs, small bays, and plenty of rock. Although only around 6 km (4 miles) long, it rises to nearly 600 metres (2,000 feet) at its highest point, Monte Solaro. It has everything to offer the coastal painter, including a superb climate, and a refuge from the winters of northern Europe.
Among the more famous artists who have stayed on this island are Albert Bierstadt and John Singer Sargent, while Adrian and Marianne Stokes honeymooned there. Although it has been claimed that Capri only became popular with painters in the late nineteenth century, its fame started rather earlier.
Carl Blechen visited the island in 1828, made hundreds of sketches there, and developed some into finished paintings when he was back in his Berlin studio. This painting of Tiberius Rocks, Capri (1828-9) seems to have been at least started en plein air, in oils on paper, although he may have finished it after his return. It shows the north coast, looking east to the peak of Monte Tiberio, with the Bay of Naples in the background.
Blechen’s superb finished painting of Marina Grande, Capri (1829) was made in the studio, though. This shows the north coast again, looking from the west of the Marina Grande towards the east, with the Tiberius Rocks and Monte Tiberio in the distance, and that may well be Vesuvius in the far distance.
Heinrich Jakob Fried’s painting of The Blue Grotto, Capri (1835) shows one of the island’s most famous sights, which has been the motif for many paintings since. This has to be visited by boat, and is at the north-western tip of the island. It features in August Kopisch’s book, published in German in 1838, describing his re-discovery of this cave in 1826, which popularised the island across northern Europe. Fried visited the cave in 1835, and probably painted this in a studio in Naples shortly afterwards, just in time for the book’s publication.
Jakob Alt’s view of Marina Grande, Capri (1836) is an extraordinary watercolour with painstaking detail. His view reverses Blechen’s, looking across the harbour from the east to the west, dropping almost to water level. Alt visited Italy in the mid-1830s, during which he too painted the Blue Grotto.
Marie-Caroline de Bourbon, Princess Caroline of Naples and Sicily, was an enthusiastic painter as well as being an avid collector of landscape paintings. The last serious Bourbon pretender to the crown of France, she visited Capri in the early 1840s, after she had been released from imprisonment in the Château of Blaye, and before moving to a palazzo on the Grand Canal in Venice. Her unusual painting of Brothers in the Carthusian Monastery of San Giacomo, Capri (1842) incorporates a vignette landscape view of the coast, almost in the manner of the Renaissance.
The great American landscape painter Albert Bierstadt visited Capri on his way back to New Bedford in 1857, following his training in Düsseldorf, Germany, only six years after he had started painting in oils. His Fishing Boats at Capri (1857) is painted in oils on paper, suggesting it may well have been started in front of the motif, and is quite unlike his mature style.
Bierstadt’s The Marina Piccola, Capri was painted on canvas in 1859, when the artist made his first journey westward to sketch American landscapes, and is more typical of the drama of his mature style. This smaller harbour is on the south side of the island, to the south-west of the town of Capri, and this view looks to the east, showing the distant sea stacks of the Faraglioni at the right.
William Stanley Haseltine was another great American landscape painter associated with the Hudson River School, and first met Bierstadt in Düsseldorf in the mid 1850s. Haseltine lived in Rome in 1857-58, and drew and painted both the Roman campagna and Capri during that time. Having made his reputation with dramatic depictions of the New England coast, he moved back to Rome in 1867, from where he travelled to paint across Europe. His paintings of Capri from this period proved popular with visiting Americans, and remain among some of the finest realist views of the island. Arco Naturale, Capri from about 1870 shows another of Capri’s famous sights, a natural rock arch on its short eastern coast.
Haseltine’s Isle of Capri: The Faraglioni, from the 1870s, shows these stacks from the north-east, and was probably painted at the Villa Malparte, to the south of the Arco Naturale. He skilfully suggests scale with the tiny boats shown at their foot, although there may be a little exaggeration.
Alessandro la Volpe was an Italian who was born in, and worked from, Naples. His View of Capri (1875) shows the island in a heat haze, from the hills above Sorrento, to the north-east.
Hans Peter Feddersen was another former student from Düsseldorf, although after Bierstadt and Haseltine. He visited Italy and Capri from April to June 1877, when he painted this view of the Marina Grande, Capri in oils, probably en plein air. Rather than follow early examples, he looks to the north across the harbour, with Vesuvius in the background.
In the summer of 1878, John Singer Sargent had just completed his studies with Carolus-Duran, and had already started to have success at the Salon in Paris. He went off on a working holiday to Capri, staying in the village of Anacapri, as was popular with other artists at the time.
Getting a local model was tricky, because of the warnings that women were given by priests. One local woman, Rosina Ferrara, seemed happy to pose for him, though. She was only 17, and Sargent a mere 22 and just developing his skills in portraiture, following the advice of his teacher Carolus-Duran. Over the course of that summer, Sargent painted at least a dozen works featuring Rosina, who seems to have become an obsession.
One, Dans les Oliviers, à Capri, he exhibited at the Salon the following year. He sent a near-identical copy back for the annual exhibition of the Society of American Artists in New York, in March 1879.
Sargent also painted a pair of views of what was probably the roof of his hotel. In View of Capri, above, made on cardboard, Rosina stands looking away, her hands at her hips. In the other, Capri Girl on a Rooftop, below, she dances a tarantella to the beat of a friend’s tambourine.
Albert Hertel trained in Düsseldorf in 1868-69, prior to which he had lived as a student in Rome for several years. He established himself as a landscape painter in Berlin, from where he seems to have returned to Italy and visited Capri in the late 1870s. His View of the Shores of Capri with People (1879) shows a small bay near Punta Carena, at the south-western tip of the island.
In 1657, one of the great scientists of the Dutch Golden Age, Christian Huygens, invented the pendulum clock, the first timekeeping device accurate enough to make a second hand worthwhile, as it typically only lost about 15 seconds per day. It was another century before John Harrison developed his marine chronometer, a clock sufficiently accurate to enable precise determinations of longitude. Another hundred years later, with the coming of railways across Europe, ordinary people started synchronising clocks so they caught their train, and our ancestors soon became the first slaves to time.
I’m beginning to wonder whether Apple intends reversing that history. Have you not noticed something odd about setting times in more recent Mac apps, how few allow you to set the seconds? You can see what has happened over the last few years in my log browsers, Ulbow and LogUI.
Most of Ulbow’s interface was written using AppKit seven years ago, and it uses a standard Date Picker with elements containing the year, month, day, hour, minute and second. Given that you can get more than 10,000 log entries in a second, I would have preferred to offer decimal seconds, but that isn’t possible within the standard AppKit picker.
LogUI was written from the start using Apple’s more recent substitute for AppKit, SwiftUI, eighteen months ago. That doesn’t use the AppKit Date Picker, but has its shiny new DatePicker instead. Components available in macOS are there limited to year, month, day, hour and minute. To be able to include seconds your code must be written for an Apple Watch, as macOS, iOS and iPadOS don’t allow seconds at all. That’s why you have to enter them in a separate TextField, although that could perhaps allow the use of decimal seconds.
When I wanted to obtain higher resolution timestamps for log entries in LogUI, I discovered that standard date formatting in macOS only resolves to milliseconds (10^-3 second), and couldn’t stretch to microseconds (10^-6 second), let alone the nanoseconds (10^-9 second) that can be obtained from Mach absolute time, as used internally in parts of macOS. Even that reference has recently become lower resolution, as each ‘tick’ in Apple silicon Macs occurs every 41.67 nanoseconds, rather than once every nanosecond as in Intel Macs.
There’s another difference between Ulbow and LogUI with regard to timestamps that you’re less likely to be aware of: Ulbow obtains its log records indirectly using the log show command, which can include the Mach absolute time of each entry. Instead, LogUI accesses those entries direct through the more recent OSLog API, which doesn’t currently expose such precise times.
Lest this appear too far removed from the world of the user, look in the menu bar clock’s settings, and you’ll see Display the time with seconds is an option, but not the default. When the clock is shown on the Lock Screen or screensaver, it only displays hours and minutes, never seconds, neither can any of the digital clock widgets supplied with macOS. While the Clock app does support decimal seconds, that’s only permitted in its Stopwatch where hundredths are displayed, as they are on an Apple Watch and other devices.
This becomes stranger still when you consider the methods used to synchronise internal clocks. Since High Sierra, macOS has used its own timed service, which Apple describes as “synchronizing the clock with reference clocks via technologies like NTP”, that’s the Internet service provided by time.apple.com as in Date & Time settings. When accessed over the Internet, it’s generally accepted that NTP should be accurate to within tens of milliseconds, although that can at times worsen to 100 milliseconds or more.
As far as I’m aware, no Mac has ever had a GPS receiver built into it, but every iPhone apart from the earliest, and those iPads with cellular support, include assisted GPS and GLONASS. Those are capable of providing time accurate to about 100 and 200 nanoseconds respectively. Even my 11-year-old car corrects its clock using GPS.
Although our Macs and devices can share almost everything else now, my Macs appear unable to adjust their clocks to the more accurate time that should be available to my iPhone. But as iOS is so shy about displaying seconds anywhere, it makes me wonder whether iPhones make full use of GPS time, or mostly rely on that obtained from the nearest cellular mast.
I’m curious whether this is a deliberate campaign to abolish seconds wherever possible, or just the result of doing what looks sufficient. Maybe I’m a mere slave to time, and the Time Lords in Apple Park are on a mission to cure me by travelling back four centuries.
Anyone familiar with Doctor Who will be aware of the power brought by control over time. Although there have been sporadic reports of problems with Apple silicon Macs keeping good time, and they may not synchronise sufficiently accurately for some purposes, they appear to have generally good control over time.
Last year I explained how macOS now uses the timed service with network time (NTP) to perform adjustments while running. This article looks at what happens before that, during startup, when the Mac has only its own devices to tell the time. Although the user sees little of this period, anyone accessing the log recorded during startup could find the timestamps of entries affected by adjustments. It may also provide insights into how Apple silicon Macs tell the time.
To investigate clock initialisation and adjustment during startup, I analysed approximately 100,000 consecutive log entries freshly recorded in the log of a Mac mini M4 Pro booting cold into macOS 26.2, following a period of about 14 hours shut down. These entries covered the period from the initial boot message for approximately 27 seconds, after I had logged in and the Desktop and Finder were displayed. This Mac is configured to Set time and date automatically from the default source of time.apple.com in Date & Time settings, and has both WiFi and Ethernet connections.
Multiple adjustments to wallclock time were recorded during that period, resulting in significant discontinuities in log timestamps. For example,11:40:15.888717 void CoreAnalyticsHub::handleNagTimerExpiry(IOTimerEventSource *)::838:messageClients of 37 available events
11:40:10.045582 === system wallclock time adjusted
11:40:10.053309 000009.664065 Sandboxing init issue resolved: "Success"
11:40:10.053447 com.apple.sandbox.reporting Sandbox: wifiFirmwareLoader(49) deny(1) file-read-metadata /Library
11:40:10.112333 === system wallclock time adjusted
11:40:10.127559 com.apple.Installer-Progress Progress UI App Starting
In the first of those adjustments, the wallclock time was retarded by up to 5.84 seconds, and in the second it was advanced by at most 0.0589 seconds.
Because of those wallclock adjustments, times recorded in the log are discontinuous. Although it’s not possible to correct for the adjustments made completely accurately, assuming that each of those adjustments corresponds to standard time (such as UTC), those can be applied backwards through times recorded in the log to bring them closer to that standard. This could result in some brief periods of entries with times earlier than preceding entries, but is as accurate an estimate possible given the data.
The narrative constructed from the log is summarised in the following table.
This starts with the initial record of the boot process, giving its UUID, within a second of the Power button being pressed (at approximately 0.0 seconds) to initiate the startup. That’s followed by a gap of just over 5 seconds before the second log entry.
The first two wallclock adjustments were made at 10 seconds, before there was any evidence of network connectivity. Those took place one second before the loginwindow was launched.
Two subsequent adjustments were made shortly after 24 seconds, immediately following the removal of the loginwindow after successful authentication. A further three adjustments followed in the 2.5 seconds after the user was logged in, while the Desktop and Finder were being prepared and displayed.
Log entries reporting the timed service was running didn’t occur until shortly before the last of those wallclock adjustments, and that was recorded in the log 0.0003 seconds before timed obtained its first external time.
A total of seven wallclock time adjustments were made before timed was able to obtain a time from any external reference. Over the first 10 seconds, before the initial wallclock adjustment, those were substantial, amounting to 5.8 seconds. For those changes to be made to wallclock time, there must be another source of time deemed more accurate, against which wallclock time can be compared and adjusted.
I’ve been unable to find any trustworthy information about internal clocks and timekeeping in Apple silicon Macs. It has been suggested (and Google AI is confident) that local reference time is obtained from the Secure Enclave. However, Apple’s only detailed account of features of the Secure Enclave fails to mention this. Initialisation of the Secure Enclave Processor also occurs relatively late during kernel boot, in this case at around the same time as the first two adjustments were made to wallclock time.
timed is able to obtain an external time against which to adjust wallclock time.為什麼高能量通量會比較好？到底怎樣才算進入高能量通量？
今年認真減脂、備賽，並參加了三場健美比賽（詳情可見這裡）；在觀察不同流派的備賽方式後，我留意到一件事：雖然大家幾乎都同意（或至少不反對）減脂時要保持「高能量通量」，甚至有選手會在減脂時仍然每天吃到 3000 大卡以上，但卻比較少看到大家認真討論高能量通量背後的原理、是否真的有效、以及怎樣才算高能量通量。
畢竟，只要能創造一樣的熱量赤字，吃進多少對減脂效果真的會有差別嗎？
今天，就來透過科學研究，帶大家更認識高能量通量的觀念，並解釋為何從科學或實務，都會比較推薦用高能量通量的方式來減脂。
一個人能減脂，通常就代表他消耗的能量比吃進去的能量還多（i.e.熱量赤字），所以身體只好燃燒脂肪來製造能量。因此，不管是吃1500大卡、消耗1700大卡，還是吃3500大卡、消耗3700大卡，都是創造200大卡的赤字，也都可以減脂。而「吃多、動更多」的方式，即是所謂的「高能量通量」。
先不管任何其他變數，理論上「只要有創造熱量赤字，不管吃多吃少都可以減脂」。那高能量通量有什麼其他優勢嗎？
我們要先建立一個背景知識：
肥胖到底是天生的還是後天的呢？確實，目前已經能找到一些跟肥胖有關聯的基因，且同卵雙胞胎的研究也顯示同樣的飲食下，雙胞胎會有較相近的體重變化（跟其他陌生人相比）。因此，肥胖跟基因是有些關聯的沒錯。
不過，基因對肥胖的影響遠遠不及環境因素。當我們脫離嚴格控制的實驗室環境，把眼光放遠到整個人口的觀察時，反而難以找到會影響肥胖的基因模式；這代表，雖然基因可以影響一個人在特定飲食下的身材變化，但現實生活中實際影響身材的主要是環境、而非基因。
除此之外，也有人類與靈長類的生態學研究發現，TDEE（每日總消耗熱量）和體型大小主要是被「食物可取得度」與「活動需求」所決定，而熱量攝取又跟 TDEE 和體型有關。簡而言之，身處越容易取得食物的環境，自然而然就會吃越多，而這多出的熱量要嘛被消耗掉、要嘛變成增加的體重。
也就是說，在現代社會這個食物可近性如此高的環境，要採取超低熱量攝取的減脂策略是很困難的，因為我們很容易就會接觸到過多的熱量。因此，從這個角度來看，高能量通量的減脂法已經先拿下一勝了。
在理想的狀況，我們消耗多少熱量，就會產生多少食慾，這樣自然而然就會處於熱量平衡。但問題是，當活動量太低時，這個正相關的食慾控制可能就會出差錯，變成活動量低時，食慾還會很高，導致吃太多而變胖。
早在1956年，Mayer et al. 就發現了工廠員工的熱量攝取會依據活動量呈現 U 字型：雖然通常來說，勞動越多的人會吃越多，但處理靜態工作、整天都坐著的員工，吃的熱量卻跟負責最大量勞動的員工相同。
Hagele et al. 在 2019 的隨機控制試驗進一步證實了活動量可以影響食慾：當受試者的活動量低下時，較容易產生飢餓相關的賀爾蒙，且吃進的熱量比高活動量時還多了 17.5%。
總結來說，活動量不足時，食慾會失去正常調控，因而容易吃進比身體所需還更多的食物，導致體重增加。從這個角度來看，高能量通量的減脂方法，再度勝利。
雖然我們通常習慣把高能量通量當成「高攝取、高活動」，但更精準的描述其實是「高攝取、高消耗」才對。這兩者有什麼不同呢？
熱量消耗可以分成：活動消耗＋非活動消耗（包含基礎代謝、食物熱效應）；不管是脂肪細胞或肌肉細胞都需要能量，所以體重較重的人，基礎代謝率其實是比較高的。因此，無論是增加活動量、還是增加體重，都可以達到高熱量消耗、也都可以變成高能量通量的狀態。這也是為什麼前述的靜態生活工人，並不會在熱量攝取變高後，體重無限增加；而是體重增加後，消耗也會隨之提高，並再次回到熱量平衡。
不過，我們在意的是減脂議題，因此通常不會把增加體重來當作高能量通量的方法。這就是為什麼我們實務上可以把「高攝取、高活動」當成「高攝取、高消耗」。
其實，只透過「多活動以增加熱量消耗」來減重並不是容易的事。根據實證指引，對多數人而言，要減重主要還是得靠飲食控制，運動只是輔助。再更進階一點的分析，甚至有所謂的 Constrained Total Energy Expenditure Model（總能量消耗限制模型）表示，超過一定的活動量後，再怎麼運動也不會增加更多熱量消耗；最顯著的例子，就是高活動的原始部落族群，每天的熱量消耗其實跟現代人差不多。（註：這個模型有很多可以討論的，如果現在會覺得奇怪、不合理，是正常的；但本文就先不細述了）
但相對的，若已減重，那高活動量就有顯著的效用：避免復胖。會復胖，就是身體想回到一個更高的能量通量，而最簡單的方法正是增加體重。不過，我們也可以透過提高活動量來達到高能量通量，這樣就不會復胖了！
老實說，就算不理會上述的一堆科學概念，高能量通量的減脂法還是有很明顯的優勢：可以正常跟家人朋友聚餐！若能量通量太低，每餐都只能吃少少幾口，那對一起吃飯的親友也是一種麻煩或壓力。若可以在高能量通量的狀態下減脂，雖然對你而言可能飢餓程度相仿（畢竟赤字相同），但至少吃的量是跟別人類似的，這樣就可以照常跟大家一起吃飯聊天了。
講到這邊，細心的讀者可能會發現，怎麼好像都還沒有定義到底要多高才算高能量通量？這是因為，高能量通量其實沒有絕對數值的定義，而是跟每個人的基礎代謝率有關。原本就體重較重、基礎代謝率較高的人，就會需要更高的熱量平衡才會處於高能量通量的狀態。
雖然還沒有精確的認定，但透過有限的研究可以估計，TDEE 比基礎代謝率高 1.7–1.8 倍就可以說他是高能量通量。所以一個基礎代謝率為 1500 大卡的人，TDEE 抓 2550 大卡就算高能量通量了。如果想減脂，那再扣 200~300 大卡，就是每天吃 2250–2350 大卡。
高能量通量的減脂方式，不只可以更自在地執行、不會給親朋好友壓力，也更適合現代社會這種食物取得度極高的環境。此外，透過提高活動量來減脂，既能調控食慾、也更能避免復胖。雖然沒有確切的數值，但大約抓 TDEE 為基礎代謝率的 1.7–1.8 倍，就能當成是高能量通量了。
主要參考資料：Melby, C. L., Paris, H. L., Sayer, R. D., Bell, C., & Hill, J. O. (2019). Increasing Energy Flux to Maintain Diet-Induced Weight Loss. Nutrients, 11(10), 2533. https://doi.org/10.3390/nu11102533
若喜歡這種健身科學解說，請追蹤我的 Medium 和 Instagram（＠vin_training），才不會錯過最新內容哦！
我把博客的模版换了，更简洁，但更好用了。
事情要从「播客封面的输出事故」开始。
我在播客后台上传的一张 1600×1600 的封面图，在通过 RSS Feed 分别同步到小宇宙和 Apple Podcast 的时候，出现了不显示或被识别成「未提供」的状态。小宇宙的后台能看见，这张图是抓到了的，但在播放页没显示；而在 Apple Podcast Connect 的后台就直接识别为「未提供」。同样的源我也尝试给到 YouTube，能抓到，能显示，但非常模糊。
第一时间我就认为是博客那头的设置问题，但具体是什么原因呢？实在是太多年没有折腾过博客的模版设计了。每个菜单我挨个检查了一遍，发现确实有个「摘录」的开关打开了，它会限制 Feed 分享出去的是完整的一篇还是只有局部的内容。这确实有影响，它导致小宇宙没抓到全文，在单集详情页里只显示了第一段话，后面还跟一个无法点击的跳转的纯文字「阅读更多」。关掉这个开关之后，小宇宙也马上就更新，能显示全文了，但封面依然没有显示出来；Apple Podcast 那边完全没动静，别说更新了，就是搜索都还搜不出来，但明明已经发布了。
我实在想不出是哪里的设置不对，就上即刻问了一下。很幸运的是，小宇宙的小伙伴立刻就开始帮我找原因。在几经周折后，最终联系上了小宇宙的技术同学，他给我看说托管源输出的图片尺寸只有 180×200 px。这就很明确了！
https://suithink.files.wordpress.com/2024/04/vol-0000.jpg?w=180&h=200&crop=1但我依然不知道为什么，因为翻遍了整个后台，都不存在一个设置 RSS Feed 输出封面尺寸的地方。别的朋友也都没遇到过这样的事。况且，一张正方形的图，就算是缩略图也应该是正方形的，比例变了又是为什么呢？
于是我意识到一件事：
这是一个行业内的标准做法，那就应该是通用的，如果别人的播客都没有这个问题，而博客后台又不存在可设置和调整的界面，那最有可能的原因大概就是，我博客使用的模板太过于老旧了。
为什么我会想到这个角度呢？
因为我博客目前用的模板，是 2013 年开始启用的，这十一年来，只在 2022 年时调整过一次，但技术内核还是原本的那套东西。然而事实上，我博客后台切换到区块编辑器已经好几年了，我还在用的这个老模板其实已经下架很多很多年了，只是因为我一直没有更换它，还在生效而已。
为了验证这件事，我先是研究了一下朋友托管播客的网站结构，确定了「封面图」在通用模版中的形式，再在我的博客后台巡了几圈，选定一些结构相似的、我也喜欢的模板，把它们套用在我的播客日志上，看看是什么表现。最后，我在区块编辑器里找到这些页面，看看它们是怎么表达和处理这张「封面图」的，有哪些可以设置的项。
至此，我锁定，问题的根源就在于，这个多年前就早已下架不再维护的老版本软件的模版，它在技术层面和现行的技术之间的差异，导致输出的封面图变成了一个比例错误的缩略图。我只需要换上一个新模版，就可以解决了。
但「换模版」这件事，其实我已经考虑好长时间了。
在这次「封面图事故」之前，我就有换新的的想法了。一方面确实是，在日常写作和新增一些页面时会明显感觉到这种技术上的代际差，只是自己懒得动，能用就不改。我相信大部分程序员也是这么想的，代码屎山不就是这么回事嘛。但如果只是换个模版，其实不用想那么久，所以另一方面更核心的是，我在同时考虑把博客的套餐升级到 Explorer 版，还想提前买下后面几年的域名使用权，因此，在我心里，模版的更新、升级、域名这三件事是合并在一起考虑的。
这次小事故，倒像是上天推了我一把。
于是乎，我下了决心，升档、域名、模版，一次性全部处理好了。我现在的博客，是一个更为简练、但更好用的全新状态。播客源的抓取也回归正常了。
从 2013、2022 到今天，眼看着我的博客越改越简练，但内容越来越充盈，我心中是欢喜的。这就是我这些年的状态，越发充盈，越不需要装饰，所有形式都让位于内容。我只要一件舒适的 T 恤就够了。年轻时喜欢说的个性，那不是通过页面、手机壳、衣裤鞋来体现的，个性是行动做派，不需要是任何视觉化的呈现。
这就是另一种「我变秃了，但更强了」。
在博客上做播客，再因为做播客而全面更新了博客，再把这个过程记录在博客上，我如果不写出来，这事儿说给人听都会觉得我有神经病哈！不过 Blog 和 Podcast 这俩完全不相关的事物，在简体中文里的说法竟然像绕口令一般相似，也是有意思。
之前有这么一个段子，说川端康成问他的几个学生，英文的“I love you”如何翻译成日语。学生们翻译成“私はあなたを爱する”之类的Google翻译体之后，川端大师抬头望了一下天，说，你们翻译得完全不对，如果是日本人的话，只要翻译成“今夜月色很好”，就可以了。
不知道为什么，假设这个事情是真的，我并不觉得它矫情。事实上，这个故事很真实，很令人信服。
学跨文化管理的时候，学到了“高语境”这么个概念。在高语境文化下，人们的真实意思并不能直接从语言的内容中推断出来，而要根据语气、表情、动作、氛围等等综合进行判断。
在商务环境下，“请问您觉得这个报价合适吗？”“听起来很合理呢，我要回去跟老板商量一下”，也许意味着后者根本无法接受这个价格。
而在恋爱环境下，“我还以为琴子是哥哥喜欢的类型呢”，“不可能，除非我智商变负”，就是个典型例子。嘴上说着不可能，但脸上藏不住的幸福感暴露了真实的心理。
————
日本和中国都是明显的高语境文化的国家，也就是说，往往话里有话，言不由衷。而在男女关系中，女性比男性要更含蓄、敏感多思，难以捉摸。试想，葬花坡上若无宝玉喊一句“只说一句话，从此撂开手”，黛玉岂不是要当下就哭死了？
高中的时候看《源氏物语》，印象最深刻的场景是，源公子从别的女人那儿回来之后，看到紫姬侧卧在床上，背朝外，只能看到她长长黑发的一个背影。
倘若这个时候，源公子没有sense地跑去问，“你是不是难过了？”贤惠的紫姬一定会否认的，也许会说，最近天气太热，不想起床。然而源公子之所以受到这么多女人的爱和等待，也是因为他很能体谅。看到紫姬无声的背影，源公子走向她，坐在床边，抚着她的头发说，“以后我都陪你”。情商之高令人发指。
高语境的爱恋有时是很困难的，有时却很有意思。来回地印证、反复地确认，若有似无地传达某个信号，努力捕捉微表情。倾城之恋里面，范柳原说喜欢流苏的理由是“一个真正的中国女人”，而流苏最大的特长则是低头。低头是一个很强大的隐藏真实信息的动作。对方讲了一个趣事，你低头；对方向你表白，你低头。不展示真心，才够矜持。
然而，这种模棱两可暧昧的态度，可能会被不了解高语境的人误读。比如，恋人电话里吵架的时候，女生说“你再也不要打电话来了!”就把电话挂了。男生再打过去，挂断，再打，关机。这个男生于是觉得女生是真的生气不想理会自己了，放弃电话，想明天再好好解释。
“你再也不要打电话来了！”和“讨厌！”是一个感觉的。这个语境是“我很生气，除非你一直一直打电话给我，我才会原谅你。”
————
我看《情书》，无论看到哪儿都恨不得会哭。日本的审美是很招人恨的。最美的是失去。最美的是死亡。樱花是美丽的，只因为它的凋谢。情书里面，男孩子对女孩的爱恋一直表现得浅浅的完全没有被察觉，而到死后，才被一点一点回忆起来。而《追忆似水年华》给人的深深的怅然，则是最好的读者反应。
上个暑假的时候，我读了两三个最后自杀的日本作家的书，真是抑郁得很。三岛由纪夫的《金阁寺》就是一本让我备受打击的书，其打击不啻于目击最心爱的人跳楼。郁闷到暴。这大概就是日本的悲剧美学的极致了吧。
为毛讲到悲剧美学了。。既然提到这个，就随便再一说。高语境的爱恋很容易出现问题，信息不对称的情况下，需要很强的互相理解与信任。远距离的恋爱之所以不易，就在于朦胧了高语境的背景。失去了眼神表情动作氛围，原本一个拥抱能解决的问题，原本撒娇卖萌的“你再不回来我就不等你了”，就会被误解放大成一场大危机。
因此心有灵犀、心心相印之类的话，都是非常高水平的恋爱程度。很高级。
傲娇是怎么一回事呢？好像在性格中就存在这种保守的态度。不愿意表明自己的态度。
因为在不知不觉中喜欢上了对方，潜意识里大喊“不好！陷进去了！”，感觉自己属于感情中的弱势者，对方的一举一动都会影响自己生活。于是反而表现出一副很强硬，很不屑的态度，以免被对方抓住痛脚。“我可没有先喜欢你哦。是你先喜欢我的呀“，是弱者自以为能够凭借立于不败之地的大把柄。
我有一阵子觉得高语境的爱恋实在是太高难度了，于是尝试着直言不讳。但在高语境成为公共知识的背景下，所有的语言都会被转译，从而造成了更大的误解。
————
有些人说，自尊心害死人。有时候自尊心是会让人受苦的。但人类之所以实现了一些文明上的辉煌，也是因为尊严，pride。物质、宝贵的生命，都可以因为尊严而放弃。
我认为，正是这种短期的似乎”不理性“，才实现了更大的理性。
高语境的使用者，莫沮丧，多沟通，多信任；高语境的”受害者“，莫否定，莫悔痛，自尊自有其代价，而人生无常，也许哪一天好事会发生。
