© Kobe Wagstaff for The New York Times
© Arash Khamooshi/Polaris for The New York Times
© Danielle James/The Flint Journal, via Associated Press
© via Joseph Perkovich
© Doug Mills/The New York Times
© Eric Lee for The New York Times
© Ilana Panich-Linsman for The New York Times
© Jordan Vonderhaar/Getty Images
© Brenda Bazán/Associated Press
One of the design features of macOS is that a file’s metadata can be stored separately from that file’s data. This is normally achieved by extended attributes, xattrs, and to aid that there’s a rich and extendable range of them. This article explains what you can and can’t do with them, as of macOS 26.4.1.
More generally, most metadata are stored within a file’s data, to accommodate operating systems and file systems that don’t have such rich features. Most image formats, for example, incorporate standard collections of metadata such as EXIF information, which are saved with the image data. PDF and Word documents have similar features. These have the disadvantage that changing the metadata results in the file data being altered, and that makes it difficult to track and to guarantee the data’s integrity. This can result in damage or corruption to the data in a PDF file during editing of comment metadata, for example. When possible it’s far better to separate metadata.
Distinguishing between data and metadata can also be tricky at times. This is easiest with non-verbal data like images and audio, where text is clearly separate from data, but it can appear more arbitrary with written documents. Some content such as copyright information or an index is universally accepted as metadata, but abstracts and appendixes may vary. Some types of document, such as official standards, draw explicit distinctions, using qualifiers like normative and informative, to assist.
These are the two standard types of metadata currently best supported in macOS, both being readily accessible in the Finder and applicable to any file or folder.
The main problem with Finder Comments is that they are primarily stored separately in the hidden .DS_Store file in the same directory as the item, although a secondary copy is written to a xattr attached to that file/folder. They’re easily accessed in the Finder’s Get Info dialog, and can be shown in List view windows, although that doesn’t work for multi-line comments. On balance, their strange storage makes them fragile and unsuitable for many uses.
Finder Tags are stored properly in a xattr, and are most widely distinguished by the coloured tag displayed. Although they can be repurposed to store text, their main value remains in categorisation. There’s a practical limit of 20-25 characters before their text label is cropped in most views, and labels for multiple items can only be shown in the Finder’s List view layout. For the majority, they are best used for allocating items to a limited number of categories, distinguished foremost by their tag colour, and aren’t suitable for more substantial text like even a brief summary.
To be generally suitable for storing text metadata for a file or folder in macOS, these should:
Of the dozens of xattrs available, I’m aware of just three that come closest to meeting all those requirements:
These are sufficiently persistent as to be preserved in iCloud Drive, and when transferred between Macs using AirDrop. Although they can be displayed in the Finder, they each require third-party software for creation and management. As explained below, this doesn’t apply to image files, which are expected to store their metadata in EXIF information within the file, and not in xattrs.
All three can be created and managed using my free Metamer, as well as with the more extensive features of xattred.
Metamer is a lightweight drag-and-drop utility to create, edit and view many different types of xattr, including the three recommended. It uses a Combo box offering 16 of the most commonly used xattrs, and you can enter the full name of any other if you need. Although it can be used to edit multi-line text, it’s designed to work best with single lines.
xattred is a general xattr editor with more extensive capabilities, and ideal for checking all the xattrs attached to a file or folder. It doesn’t offer the conveniences of Metamer, though.
Each of these three xattrs is displayed in the More Info section of the Get Info dialog, and depending on settings, they can also be shown in the Finder’s preview pane when enabled in Preview Options for that file type. The latter is explained in more detail here, and can appear counter-intuitive at times. However, they can only be added and displayed for supported file types. For example, JPEG and PNG image files can’t display these three xattrs in Get Info dialogs or in the preview pane, but PDF, RTF, text and many other file types can.
None of the three can be listed for multiple files in any of the Finder’s view layouts.
All three are available in the list of search terms available in the Other item at the foot of the search term menu in a Finder Find window, as listed above.
When researching this article, I discovered some odd behaviours that render some xattrs both invisible and undiscoverable by Spotlight search. I hope to describe those fully tomorrow if I can get my head around them.
Extended attributes aren’t unique to macOS and Apple’s other OSes, but they have the longest and richest history, going right back to the first versions of Mac OS. Until the advent of Mac OS X they were resource forks, structured metadata that stored everything from executable code to keyboard layouts. After a shaky first four years in early versions of Mac OS X, 10.4 introduced extended attributes, xattrs, that steadily became used more extensively.
All files in HFS+ and APFS (and other file systems) contain a fairly standard set of metadata known as attributes, information about a file such as its name, datestamps and permissions. Xattrs are extensions to those that contain almost any other type of metadata, the first notable xattr coming in Mac OS X 10.5, named com.apple.quarantine. That contains quarantine information for apps and other files downloaded from the internet, in a format so ancient that the quarantine flag is stored not in binary but as text.
The quarantine xattr demonstrates some of the valuable properties of xattrs: it can be attached to any file or folder without changing its data, and isn’t included when calculating CDHashes for code signatures. It can thus be added safely without any danger of altering the app or its code, although it does change the way that macOS handles the code, by triggering security checks used to verify it isn’t malicious. Once those have been run, the flag inside the quarantine xattr can be changed to indicate it has been checked successfully.
Far from being a passing phase, or dying out as some had expected, xattrs have flourished since those early days. This has happened largely unseen by the user: few alter anything revealed in the Finder’s Get Info dialog, although they’re used to store some forms of visible metadata such as Finder tags, and the URL used to download items from the internet.
Xattrs are named using a reverse-URL format like com.mycorp.setting. There’s no official name registry, as that should suffice to ensure each type remains unique. Editing xattrs is normally performed silently: you’re not made aware of changes in the quarantine xattr, and in most cases the only way to manage xattrs is to use the xattr command tool, or one of very few apps like xattred that can edit and manage them.
Xattrs aren’t stored with a file’s data, nor with its normal attributes.
For smaller extended attributes up to 3,804 bytes, their data is stored alongside the xattr in the file system metadata. Larger extended attributes are stored as data streams, with separate records, but still separate from the file data. Apple doesn’t give a limit on the maximum size of xattrs, but they can certainly exceed 200 KB, and each file and folder can have an effectively unlimited number of them.
Metadata varies in its useful lifetime. Some xattrs are intended to have a short life and then either be rewritten or discarded, while others are expected to be more or less permanent. Files that are copied to non-native file systems including FAT and ExFAT volumes can preserve xattrs in hidden shadow files, but those copied to NFS will have all their xattrs stripped.
Moving a file with xattrs within the same volume shouldn’t affect those xattrs, as they remain within the same file system, but copying them to another volume, even if both use APFS, may leave some of them behind if they’re considered to be ephemeral.
At least two xattr types may be protected by System Integrity Protection, SIP, and thus can’t be directly removed by the user. This is most widespread in the MACL xattr, com.apple.macl, but can also be seen sometimes in provenance, com.apple.provenance. The way that works is quite distinctive, in that cutting or deleting the xattr is successful for an instant before macOS adds the xattr back. As SIP protection doesn’t survive copying to another volume, when you need to remove a MACL xattr you can do so on a copy of the file on a different volume.
The most complex situation is when a file with xattrs is moved to iCloud Drive. The Mac that originated that file is likely to retain most if not all of its xattrs, because the local copy remains within the same volume and file system. However, not all xattrs are copied up to iCloud storage, so other Macs accessing that file may only see a small selection of them. The rules for which xattrs are to be preserved during file copying, including in iCloud Drive, are baked into macOS, and are outlined in the Appendix at the end.
In 2013, as part of its enhancements for iCloud in particular, Apple added support for flags on xattrs to indicate how those xattrs should be handled when the file is copied in various ways. Rather than change the file system, Apple opted to append characters to the end of the xattr’s name.
If you work with xattrs, you’ve probably already seen this in those whose name ends with a hash # then one or more characters: those are actually the flags, not part of the name, what Apple refers to as a ‘property list’. To avoid confusion I refer to them as xattr flags. A common example of this is com.apple.lastuseddate#PS, which is seen quite widely.
When first introduced in Mac OS X, no provision was made for xattrs to have type-specific preservation, and that was added later using flags suffixed to the xattr’s name. For example, the com.apple.lastuseddate xattr found commonly on edited files is shown with a full name of com.apple.lastuseddate#PS to assign the two flags P and S to it, and the most recent xattr com.apple.fileprovider.pinned, used to mark files in iCloud Drive that have been pinned, has the two flags P and X assigned to it for a the full name of com.apple.fileprovider.pinned#PX.
This is a kludge, as you normally have to refer to the xattr name including its flags, although the flags aren’t really part of its name. It’s further complicated by a set of system tables for some standard xattr types that don’t have flags suffixed, but are treated as if they do. One notable example of those is the quarantine xattr com.apple.quarantine, which is handled by macOS as if it has the PCS flags attached, although those are never used when referring to it by name.
There are also lower case flags that can be used to override those set in system tables, although those appear to be used exceedingly rarely, and I don’t recall ever coming across them. In theory, if you were using a new type based on the standard com.apple.metadata: family, com.apple.metadata:kMDItemNew, you could alter its behaviour to some similar types with the flags psB, as in com.apple.metadata:kMDItemNew#psB. I have no idea whether that would be respected in practice. For the rest of this article, I will ignore the existence of those lower case flags.
File operations involving decisions about the preservation of xattrs are simplified into the following intents:
Login
cp, is labelled XATTR_OPERATION_INTENT_COPYXATTR_OPERATION_INTENT_SAVEXATTR_OPERATION_INTENT_SHAREXATTR_OPERATION_INTENT_SYNCXATTR_OPERATION_INTENT_BACKUP.As of macOS 15.0 (including 26.0), the following flags are supported:
XATTR_FLAG_CONTENT_DEPENDENT ties the flag with the file contents, so the xattr has to be recreated when the file data changes. This may be appropriate for checksums and hashes, text encoding, and position information. The xattr is then preserved for copy and share, but not in a safe save.XATTR_FLAG_NO_EXPORT doesn’t export or share the xattr, but preserves it during copying.XATTR_FLAG_NEVER_PRESERVE ensures the xattr is never preserved, even when copying the file.XATTR_FLAG_SYNCABLE ensures the xattr is preserved during syncing with services such as iCloud Drive. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this flag overrides that.XATTR_FLAG_ONLY_BACKUP keeps the xattr only in backups, including Time Machine, where there’s no desire to minimise what’s backed up.XATTR_FLAG_ONLY_SAVING keeps the xattr only when saving and in backups, including Time Machine (macOS 15.0 and later only).There’s another system limit that must be adhered to: total length of the xattr name including any # and flags cannot exceed a maximum of 127 UTF-8 characters.
These are hard-coded in source, where * represents a ‘wild card’:
com.apple.quarantine – PCS preserved in copy, sync, backupcom.apple.TextEncoding – CS copy, share, sync, backupcom.apple.metadata:kMDItemCollaborationIdentifier – B backupcom.apple.metadata:kMDItemIsShared – B backupcom.apple.metadata:kMDItemSharedItemCurrentUserRole – B backupcom.apple.metadata:kMDItemOwnerName – B backupcom.apple.metadata:kMDItemFavoriteRank – B backupcom.apple.metadata:* (except those above) – PS copy, save, sync, backupcom.apple.security.* – S or N depending on sandboxing, see belowcom.apple.ResourceFork – PCS copy, sync, backupcom.apple.FinderInfo – PCS copy, sync, backupcom.apple.root.installed – PC copy, backup.System defaults for com.apple.security.* depend on whether the app performing the file operation is running in an app sandbox. Non-sandboxed apps apply S to preserve the xattr for copy, save, share, sync, backup; for sandboxed apps N is applied so the xattr is never preserved, even when copying the file.
We can now revisit the list of intents, and establish the effects of xattr flags on each, as:
XATTR_OPERATION_INTENT_COPY preserves xattrs that don’t have flag N or B or XXATTR_OPERATION_INTENT_SAVE preserves xattrs that don’t have flag C or N or BXATTR_OPERATION_INTENT_SHARE preserves xattrs that don’t have flag P or N or B or XXATTR_OPERATION_INTENT_SYNC preserves xattrs if they have flag S, or have neither N nor BXATTR_OPERATION_INTENT_BACKUP preserves xattrs that don’t have flag N.Finally, Apple provides separate information on how xattrs are synced by FileProvider, for iCloud Drive and third-party cloud services using that API. This confirms that the S flag should sync a xattr, but is vague on other flags, simply stating “some older attributes are also synced”. However, a cap is applied on the maximum size of xattrs that are syncable, at “about 32KiB total for each item”. If the xattrs exceed that limit “the system automatically makes some of the attributes nonsyncable.” More puzzlingly, it states “the resource fork is content and isn’t included in the extended attributes dictionary.”
xattr_flags.h, xattr_flags.c, xattr_properties.h in copyfile source, e.g. at Apple’s OSS Distributions Github
man xattr_name_with_flags(3), included in copyfile source
FileProvider (Apple).
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.
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
為什麼高能量通量會比較好？到底怎樣才算進入高能量通量？
今年認真減脂、備賽，並參加了三場健美比賽（詳情可見這裡）；在觀察不同流派的備賽方式後，我留意到一件事：雖然大家幾乎都同意（或至少不反對）減脂時要保持「高能量通量」，甚至有選手會在減脂時仍然每天吃到 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），才不會錯過最新內容哦！
之前有这么一个段子，说川端康成问他的几个学生，英文的“I love you”如何翻译成日语。学生们翻译成“私はあなたを爱する”之类的Google翻译体之后，川端大师抬头望了一下天，说，你们翻译得完全不对，如果是日本人的话，只要翻译成“今夜月色很好”，就可以了。
不知道为什么，假设这个事情是真的，我并不觉得它矫情。事实上，这个故事很真实，很令人信服。
学跨文化管理的时候，学到了“高语境”这么个概念。在高语境文化下，人们的真实意思并不能直接从语言的内容中推断出来，而要根据语气、表情、动作、氛围等等综合进行判断。
在商务环境下，“请问您觉得这个报价合适吗？”“听起来很合理呢，我要回去跟老板商量一下”，也许意味着后者根本无法接受这个价格。
而在恋爱环境下，“我还以为琴子是哥哥喜欢的类型呢”，“不可能，除非我智商变负”，就是个典型例子。嘴上说着不可能，但脸上藏不住的幸福感暴露了真实的心理。
————
日本和中国都是明显的高语境文化的国家，也就是说，往往话里有话，言不由衷。而在男女关系中，女性比男性要更含蓄、敏感多思，难以捉摸。试想，葬花坡上若无宝玉喊一句“只说一句话，从此撂开手”，黛玉岂不是要当下就哭死了？
高中的时候看《源氏物语》，印象最深刻的场景是，源公子从别的女人那儿回来之后，看到紫姬侧卧在床上，背朝外，只能看到她长长黑发的一个背影。
倘若这个时候，源公子没有sense地跑去问，“你是不是难过了？”贤惠的紫姬一定会否认的，也许会说，最近天气太热，不想起床。然而源公子之所以受到这么多女人的爱和等待，也是因为他很能体谅。看到紫姬无声的背影，源公子走向她，坐在床边，抚着她的头发说，“以后我都陪你”。情商之高令人发指。
高语境的爱恋有时是很困难的，有时却很有意思。来回地印证、反复地确认，若有似无地传达某个信号，努力捕捉微表情。倾城之恋里面，范柳原说喜欢流苏的理由是“一个真正的中国女人”，而流苏最大的特长则是低头。低头是一个很强大的隐藏真实信息的动作。对方讲了一个趣事，你低头；对方向你表白，你低头。不展示真心，才够矜持。
然而，这种模棱两可暧昧的态度，可能会被不了解高语境的人误读。比如，恋人电话里吵架的时候，女生说“你再也不要打电话来了!”就把电话挂了。男生再打过去，挂断，再打，关机。这个男生于是觉得女生是真的生气不想理会自己了，放弃电话，想明天再好好解释。
“你再也不要打电话来了！”和“讨厌！”是一个感觉的。这个语境是“我很生气，除非你一直一直打电话给我，我才会原谅你。”
————
我看《情书》，无论看到哪儿都恨不得会哭。日本的审美是很招人恨的。最美的是失去。最美的是死亡。樱花是美丽的，只因为它的凋谢。情书里面，男孩子对女孩的爱恋一直表现得浅浅的完全没有被察觉，而到死后，才被一点一点回忆起来。而《追忆似水年华》给人的深深的怅然，则是最好的读者反应。
上个暑假的时候，我读了两三个最后自杀的日本作家的书，真是抑郁得很。三岛由纪夫的《金阁寺》就是一本让我备受打击的书，其打击不啻于目击最心爱的人跳楼。郁闷到暴。这大概就是日本的悲剧美学的极致了吧。
为毛讲到悲剧美学了。。既然提到这个，就随便再一说。高语境的爱恋很容易出现问题，信息不对称的情况下，需要很强的互相理解与信任。远距离的恋爱之所以不易，就在于朦胧了高语境的背景。失去了眼神表情动作氛围，原本一个拥抱能解决的问题，原本撒娇卖萌的“你再不回来我就不等你了”，就会被误解放大成一场大危机。
因此心有灵犀、心心相印之类的话，都是非常高水平的恋爱程度。很高级。
傲娇是怎么一回事呢？好像在性格中就存在这种保守的态度。不愿意表明自己的态度。
因为在不知不觉中喜欢上了对方，潜意识里大喊“不好！陷进去了！”，感觉自己属于感情中的弱势者，对方的一举一动都会影响自己生活。于是反而表现出一副很强硬，很不屑的态度，以免被对方抓住痛脚。“我可没有先喜欢你哦。是你先喜欢我的呀“，是弱者自以为能够凭借立于不败之地的大把柄。
我有一阵子觉得高语境的爱恋实在是太高难度了，于是尝试着直言不讳。但在高语境成为公共知识的背景下，所有的语言都会被转译，从而造成了更大的误解。
————
有些人说，自尊心害死人。有时候自尊心是会让人受苦的。但人类之所以实现了一些文明上的辉煌，也是因为尊严，pride。物质、宝贵的生命，都可以因为尊严而放弃。
我认为，正是这种短期的似乎”不理性“，才实现了更大的理性。
高语境的使用者，莫沮丧，多沟通，多信任；高语境的”受害者“，莫否定，莫悔痛，自尊自有其代价，而人生无常，也许哪一天好事会发生。
关于作者
本书作者是英国社会学家约翰·厄里，剑桥大学社会学博士，曾在英国著名学府兰开斯特大学任教，主要研究方向是旅游人类学、文化学。“游客凝视理论”是他最著名的学术成果。关于本书本书出版于90年代初，直到现在，这个“游客凝视理论”都是旅游研究的一个重要工具。虽然是一部学术著作，但是它研究的，其实是人们看待世界的方式，而旅游活动中的一些现象很有代表性，很适合来分析这个问题。本书给了我们一个非常好的视角，来重新看待我们所处的这个巨大的消费社会。核心内容本书从理论的高度去分析旅游这个热门现象，其中最重要的一个结论就是，你对旅游的期待也好，体验也好，都不是天然的，而是被建构出来的。旅游的整个过程，都是想象大过于真实，并且那些值得看的景观，也都是围绕这种想象才成为景观。这
是一本讲旅游的书，它从理论的高度去分析旅游这个热门现象，其中最重要的一个结论就是，你对旅游的期待也好，体验也好，都不是天然的，而是被建构出来的。旅游的整个过程，都是想象大过于真实，并且那些值得看的景观，也都是围绕这种想象才成为景观的。说到这里，你可能会觉得奇怪，旅游这事还不是自己说了算，去哪玩，看什么，怎么玩，都是自己决定的，怎么是被设计的呢？其实事情可没这么简单。我跟你讲个有趣的事情。有一年，巴黎市长到北京来做城市推广，欢迎大家去巴黎旅游。新闻发布会上，有一位女记者提了这么个问题，她说市长先生，现在去巴黎旅游的中国人太多了，我去巴黎的话，要怎么才能避开中国游客呢？市长先生就懵了，一个中国游客到了巴黎，却想避开其他的中国游客？为什么会有这种问题？他挠了半天头，也不知道该怎么回答。其实就连我们自己也有体会，出国旅游，还真就想躲开国内那些举着小旗吵吵嚷嚷的旅游团，让自己彻底沉浸在异国他乡那种气氛里。那么问题来了，你为什么会有这种想法，这背后有哪些深层的原因呢？就让我们带着问题，去书中寻找答案吧。那么，我们为什么要读这本书呢？当然，旅游现在是个很流行的事，但你可能会说，我充其量只是游客，又不是研究旅游行业的学者或者专业人员，为什么要了解这些学术上的东西呢。那么我要告诉你的是，今天要讲的重点，其实是你看待世界的方式，而旅游活动中的一些现象很有代表性，很适合来分析这个问题。在传统西方文化中，人的观看实践具有非常重要的意义，自然科学的发展离不开观察，哲学家们也花费了很大的精力去讨论感官经验是否是知识的根本来源。进入20世纪，思想界对于观看的研究更加深入了，“看”包含了一系列有关文化、种族、性别与政治的话题。特别是“凝视”这个词，出现的频率很高，它有时是实际的“看”，有时是隐喻的“看待”，暗示着背后的权力关系。这一点，我们下面马上就会讲到。那么厄里这本书，就是给了我们一个非常好的视角，来重新看待我们所处的这个巨大的消费社会。关于这本书的解读，我会分为三个部分：第一部分，“游客”和“凝视”是如何定义的；第二部分，人文景观和自然景观是如何满足游客的幻想与期待的；第三部分，我们讲一讲摄影与旅游的关系。我们出去玩，总会拍照片发朋友圈，我们也会看其他朋友都去哪里玩，拍了什么照片。旅游跟拍照的关系也是非常值得探讨的一件事。第一部分我们先进入第一部分，究竟什么叫“游客的凝视”呢？“游客”就不用说了，我们都当过游客，也许听这本书的时候，你正是一个游客。不过“凝视”二字，却需要我们先来说一说。凝视这个概念，是法国著名思想家米歇尔·福柯提出来的。“凝视”作为一个特定术语，是一种特殊的观看，往往会涉及主客体之间的关系，尤其是权力关系。怎么理解呢？你可能认为，凝视，不就是盯着看嘛，是一个很客观的、很自然的行为。但其实，所谓“凝视”并不是一般的“看”这么简单。你要注意到，这里面有一个关键因素，就是凝视这件事，是从观看者的视角出发的，观看者是主体，被观看的东西是客体，所以它是一件主观的事情。拿福柯谈到的医学凝视来说，医生对病人的凝视，显然不是普通的看，它是一种诊断和判定，判定的基础是一整套医学专业知识，具有明显的权威性。再举一个例子，就是女性主义研究中经常提到的“男性凝视”，指的是在男权社会中，女性往往处于被观看、被评价的地位，这种凝视往往含有很浓的欲望色彩和支配的意味。这两种凝视，都不仅仅是个体行为那么简单，而是制度化的，在整个社会的大范围的活动中形成的。社会通过观念、技术、体制这些东西，影响着一个人的凝视，比如凝视什么东西，如何凝视，如何去判断好坏对错等等。那么说到游客的凝视，就是说，我们在看特定的景观时，会受制于个人的经验和记忆，各种潜在的规则和风格，还有四处流传的影像和文本等等。它们共同构成了我们凝视的框架，在潜移默化中指导着我们看什么东西，如何去看。简单来说就是，我们无论是去自然景区、人文小镇，还是迪士尼公园，其实在我们的潜意识中，已经偷偷被植入了对这个地方的想象和期待。理解了凝视是一种带有强烈主观性的活动，我们现在就回过头来考察一下这个凝视者的主体，也就是游客。游客是一个天然的身份吗？你可能要说，出去旅游的人就叫游客呗。实际上不是这么简单，我们这里说的游客，是指一个群体。游客是现代社会的产物，是在大众旅游业发展起来之后出现的。当一个游客是现代经验的一大特色。夸张点说，它已经变成现代社会身份地位的标志，也是维持身体健康、开阔眼界的必要途径。踏进旅游区，就好像取得了一张门票，让你进入了一个消费社群。当你迈入商品殿堂，仿佛就获得了当代社会的认可，成为一名“合格”的消费者和公民。但这一切的历史不过短短100多年。根据厄里的分析，在西方世界，游客凝视最早可以追溯到19世纪中叶，它是一个特殊的时代产物。从那个时候开始，集体旅行的工具、旅行的渴望、摄影技术，开始结合了起来。在此之前，旅行并不是一件普遍的事情。由于交通不发达，旅行成本很高，只有很少一部分社会精英才有机会外出旅游，“游客”还远远没有成为一个可以独立出来的身份。19世纪，随着工业革命席卷西欧，工业城市在各地兴起，在新兴的工厂里，工作成了在特定时间、特定空间内进行的活动，和娱乐、宗教、节庆活动区分开了。有了规定时间的工作，才有了规定时间的假期，这是大众旅游兴起的条件。既然假期是作为工作的反面出现的，那么旅游作为实现假期的一种方式，最重要的一个目的就是逃离工作，或者说，是要逃离那种按时上下班、千篇一律的生活方式。简单说来，人们想从旅游和假期中得到的东西，往往刚好和日常生活相反。中产阶级想当一天的农夫，而中下阶级呢，则想做一天的富豪。当然，这是一个比较极端的例子，但道理大体是这样。感受不一样的事物，遇见不一样的人，是人们对外出旅游的基本期待，可以说，旅游就是从这种期待开始的。而期待和幻想，在许多学者看来，正是现代消费主义的两大要素。光是购买、使用、体验，还无法让消费者满足，人们的满足感其实是来自于内心的期待和幻想。幻想什么呢？幻想自己追求愉悦的这个过程。因此，人类花钱消费不全然是因为物质上的需求，人们真正向往的是亲身体验自己幻想中的场景。正因为这种令人心驰神往的完美体验在现实生活中极少发生，人们在每一次幻灭之后，就更期待产品和服务能推陈出新，提供新鲜感。当代消费主义的核心就是一场求新求变和永不满足的循环。要将它维持下去，关键就是要不断地创造人们的期待。到这里，我们的第一部分讲完了。我们也可以回答那个女记者的问题了，她想在巴黎避开中国游客，这个要求太正常了。她到巴黎是要凝视这个浪漫之都的，街上都是亲吻的男女，地铁里的乘客都很有文化，都在读书，咖啡馆坐的应该都是法国知识分子和作家啊。结果呢？太多的中国人去巴黎了，街上到处能碰见中国人，买完奢侈品，拎着购物袋，坐在咖啡馆里。看见这样的场景，那位要凝视巴黎的游客就会立刻出戏，所以，她提出的问题其实本质上就是，怎么保证让中国游客对巴黎的凝视能够进行下去。第二部分我们带着这个问题进入第二部分。巴黎是浪漫之都，大英博物馆是知识汇聚之地，现代旅游业，离不开这样的期待和幻想。接下来，我们就围绕这个出发点，详细分析一下游客的凝视以及凝视的对象是如何建构的。现代旅游业要不断生产旅游凝视的对象，首先要努力创造和维持游客的期待，这是一个非常复杂的生产过程。一个景点的凝视对象，需要跟日常生活能体验到的东西有明显区别，要常规性地出现，还得具有明显的意义，而且，它还必须能让旅游业者从中获利。这样做的结果，就是生产出一批批的“符号”。什么是符号呢？我举个例子你就明白了。如果我说起英国乡村，你脑海里会浮现出什么呢？大概是一片宁静的田野风光，带花园的乡间小屋。如果说到德国，大概是群山之间矗立的城堡，说到巴黎呢，就是街头拥吻的恋人，和塞纳河边的咖啡馆了。这些都是典型的旅游符号。旅游业的推动者们花费了很大的工夫去培养游客，在他们去之前，告诉他们什么值得看，以及应该怀着什么心情去看。到了景点之后，现场还会提供清楚的指示，一步步指引你去看那些已经满心期待的东西。当游客看见两个青年男女在巴黎街头接吻，立即就知道这是“永恒浪漫的巴黎”；当看见英国农庄篱笆里的玫瑰，立即感受到所谓的“纯正古老的英格兰氛围”。不知不觉中，游客们就被培养成了业余的符号学家，至于你看到的风景是不是天然就是那样，古迹是不是历史上原原本本的样子，这些问题已经被有意无意地排除在旅游活动之外了。刚才我们说的这些，其实都可以归为一种“当代符号旅游”。构建这种符号旅游，最突出的例子就是各种主题园区、度假村和所谓的风情古镇，也就是通过空间设计来构建这些符号。它们首先会设计出一些著名的符号，把视觉元素缩减成少数几个特色，之后再把它们强化、夸张，好让游客明确地去凝视。法国当代哲学家鲍德里亚有个著名的论点说，我们消费的东西，充其量是一堆符号罢了。人类通过交换符号价值来建构社会认同，但却是以一种奇观的精神接受它。这话听上去有点抽象？我们来用一些例子来解释。比如现在国内的各种特色古镇，不论身在哪个省份，都是相似性大过差异性，商店都是全国连锁，这就不必说了，即便是为了凸显地方特色的建筑，因为大多是后来复建的，常常会出现地域和时代的差错，但普通游客也看不出来，因为这些表面看上去风格一致的元素符合他们的期待，已经能达到让游客去凝视的要求。小桥流水、木头牌匾、青砖黑瓦，管它们是不是真的，都是合理的符号。反倒是那些现代的、日常的东西容易造成违和感，于是“贴心”的景区管理者们会把音箱、垃圾车、路灯等等，都给移除或者改装，让真实的东西尽量贴合游客的凝视和想象。再比如迪士尼这类的主题公园，更加能凸显“奇观”这个特点。什么是奇观呢？就是你在现实生活中很难见到的东西。迪士尼乐园把这些只有在动画片里出现的场景，做得看起来千真万确，人物栩栩如生，有些仿古的物件，比真的古董还要像回事儿。理论家们称之为“过度真实”，人们能看到的、感触到的表层的东西，比原景物显得更真切，也更容易接受。迪士尼乐园暗示我们，仿造出来的真实比较符合我们的幻想，科技比自然更能带给我们真实感。甚至连我们最信任的一些机构，比如著名的博物馆、古迹遗址，也无法逃脱符号化的建构网络。作者提到，19世纪中叶开始，外出旅游，参观重要遗址、展览、建筑等等，观摩一个社会多年积累的成就，已经慢慢发展成公众的文化意识。也是从那个时候开始，现代人对历史遗迹和文化遗产变得十分着迷。其中一个原因是，在价值观多元化、生活节奏日益加快的现代社会，人们充满困惑，总是感到焦虑和失望，这时就会产生强烈的怀旧情绪。消费主义会利用这种怀旧情绪，挑选一些大家希望看到的历史记忆，再把它们用人们期待的方式呈现出来。在这里我们特别提一下博物馆旅游。说到博物馆，其实它的起源是私人收藏，收藏家把自己收集来的奇珍异宝存放在一起，关起门来自己欣赏，或者是给专门的学者来研究，一般人根本见不到这些宝贝。直到19世纪初，欧洲才有了现代意义上的博物馆，开放给一般民众参观。逛博物馆自然是一件好事，也是如今观光旅游的一大潮流，但真正懂得如何参观的人还是不多。有人形容当今的许多游客是“现代朝圣者”，把旅游手册当作宗教教材来使用。他们总把手册上让你看的东西当作最紧要的东西。文物的价值取决于名气大不大，手册或攻略上写没写，结果观光旅游仿佛成了一套仪式流程，什么东西该看，按什么顺序参观，一切都成了某种套路。说穿了，对于这样的游客来说，去博物馆只是去感受一种特殊的氛围，博物馆像一座神圣的殿堂，象征着国家的权力、学者的知识和艺术家的天赋。不懂绘画的游客，在面对那些散发着神圣光芒的古典作品时，只能随着大流，向它们的名声、价值或权威性致敬。作品的价值并非来自作品本身，而是因为它被人们鉴定为稀世珍品，也就是说，这些价值连城的真迹，在此情此景之中，也沦为了一种符号。以上的部分，我们用一些例子解释了一个问题，那就是人文景观是如何被符号化，变成游客凝视的对象的。我们来简单总结一下，在以人文景观为主的景区，围绕游客的期待和想象，往往会出现一系列“符号”。这些符号有的代表历史，有的代表高雅，有的代表异域风情，等等等等，游客通过这些符号去解读和实现自己的凝视。接着，游客的凝视行为又强化了这些符号，旅游活动就这样滚动推进下去。人文景观有它的建构方式，下面我们要讲的是，甚至连自然景观也是建构的结果。自然景观的建构，不像人文景观那样，要真的去建造或设计什么东西出来，它更多是一种观念上的、想象上的建构。在很长的一段历史时期里，人类是自然的一部分，因此也不涉及什么主体与客体的对立关系。人的力量也远远没有强大到可以凌驾于自然之上，谈不上支配自然、主导自然，因此也就不存在凝视、被凝视这种关系。这从人类的视觉历史，或者说主要是绘画历史之中也可以看出来。西方文艺复兴之前，风景只能在绘画中充当背景，放在主要人物的背后，起衬托或象征作用，人的主要任务还是突出主体，挣扎着从自然中独立出来。文艺复兴之后，风景画才开始兴起了，说明西方人从这时开始重新审视大自然，山川草木有了新的意义。人学会了把自然框起来，进行选择、解读和修改，这才制造出了风景。把自然纳入旅游活动的范畴，让风景成为旅游凝视的对象，当然也与人对自然的观念密切相关。18、19世纪之交，社会价值观出现了重大转变，这跟浪漫主义运动的发展有关。浪漫主义重视强烈的情绪和感受，强调诗意、神秘性、个体的精神愉悦。雪莱、拜伦、柯勒律治这些诗人们认为，人类感受得到自然的情绪，能从壮丽的美景中获得极大的快乐。浪漫主义带动了风景旅游的风潮，教导民众欣赏自然。接下来的一百年里，任何一种自然景象都被当成风景，阿尔卑斯山脉和英格兰湖区，就是在诗人华兹华斯的大力赞美之下，变成举世闻名的风景胜地的。18世纪末，风光旅游先是席卷了英国，随后迅速横扫全欧洲，游览风景名胜变成一种可以抒发感情的活动。这一套鉴赏标准造就了全新的观看方式，也就是超然的、诗意的凝视。如何选择观赏的地点呢？最好是让观看者既能保持距离，又能沉醉其中。游客的姿态，看似超然，其实主宰着一切。人凭着经过训练的高超眼光，再加上风景画、照片等各种再现技术，以人为的方式营造自然环境。风景是自然的，但更是文化的，自然景观背后更重要的问题是，人类怎么控制和拥有自然，并从自然中得到乐趣。观看者只提取他想看的东西，不光提取，还要对这些东西进行调整和修改，怎么修改呢？那就要看约定俗成的“好看”是什么样。比如在一个修改好了的乡村景观中，农机、电缆、荒地、死掉的动物这些东西，你是不会看到的。欣赏是一部分，到了20世纪以后，人不光要欣赏风景，还要大量占有和消费风景。办法很简单，主要就是消费风景影像。所谓“浪漫凝视”，赞扬的就是那种“适合放在图像里的美”。我们说的“风景如画”也是这个意思，画本来是再现，但再现已经超过了真实。在全世界范围内，人们大量购买风光照片、明信片等等，用这种办法来消费和想象旅游景点。很多时候，人们是先看到了图画，之后才去到那个相应的地方，这样一来，自然景观反而变成了那张图的复本。这种凝视，意味着游客欣赏美景时，必然会被卷入文本、影像的世界里。游客所凝视的，与其说是自然风光，不如说是各种广告和大众媒体上常见的，那种理想化了的情景。就算无法亲眼见识自然界的美景，人们还是能够感受它，在心中看到它。有时候游客去了，发现实景并不如想象的那般美好，但最终盘踞在他们脑海中的依旧是那些完美再现的画面，仿佛那是自己亲眼目睹的一切。我们简单总结一下上面这一部分，自然虽提供了山川河流、草木与鸟兽，但风景之所以成为风景，却是文化作用的结果，人知道要去看，并学会怎么看，再进一步把它纳入现代旅游凝视的范畴，每一步都离不开社会的建构。在这一部分的末尾，我们已经提到了再现的影像对游客凝视的影响，随着摄影技术的普及，这个主题变得很突出，也很特别，下面我们就把它展开来，详细解释一下。这也就是我们要讲的第三部分，旅游与摄影之间难分难解的关系。第三部分摄影技术发明以前，一种景观是固定在当地的，移动不了，要想看只能人自己过来。画家虽然也能把它们画下来，展示给别人，但绘画毕竟很耗时，复制起来也很困难。有了机器之后，照片复制起来就容易多了，而且一旦刊登在报纸、杂志、广告上，就能实现极大范围的流通。相片逐渐变成成本低廉的量产物，人类通过照片，全世界都唾手可得。到19世纪下半叶，影像的数量成倍增长，各种明信片、旅游指南、私人照片遍布全球。这产生了极大的影响，有学者认为，那个时代的人们，把世界想象成一场展览，全世界被摆得像张图画，呈现在观众面前，供人观看和体验。所谓的真实世界，成了一场壮观绚丽的展示。不仅如此，人们还开始学会用图画的思维去构思和捕捉这个世界，随着视觉技术日益繁复，视觉也变成了最重要的感官。到如今，旅游经济和旅游文化已经离不开摄影，游客凝视与相机、照片的发展息息相关，越来越受到来自摄影的影响。拍照提高了旅行的吸引力，影响着旅程的规划，甚至取代了真正的旅行。很多时候，人就是为了拍照、收集照片才出门的。就算不是为了摄影而旅游，现在的游客也会习惯性地拿着相机和手机，只要看见什么稍微特别一点的东西，马上下意识地拍下来。游客们不停地观看他人，记录他人，同时也被观看，被记录。他们对任何地方都充满好奇，凡是值得拍的对象、事件、人物，他们都想用相机一探究竟。光影是世间最短暂的东西，转瞬即逝，而摄影的魔法却能将它固定在一个永恒的地方，这种魔力深深地吸引着游客。通过拍照，他们仿佛感觉能将那个特定时刻据为己有。但这同时也带来一个问题，被照片固定下来的这一时刻，是真实的吗？我们来听听法国思想家罗兰·巴特的回答，他说摄影很容易给人身临其境的错觉，让人误以为回到了现场，但其实是人在照片的刺激下，展开了一趟想象之旅。游客总以为摄影是写实的，一张照片好像就是世界的一部分或一个片段，不会说谎。但摄影其实就和绘画一样，毫无疑问是一种创作，关键就在于对现实材料如何取舍，如何加工。摄影者对于某些显而易见的特质，往往视而不见，但在其他一些地方却花工夫美化。有时拍照的人会刻意忽略人眼看得一清二楚的事物，反倒是煞费苦心地捕捉人眼几乎看不到的细枝末节。在滤镜和修图大行其道的今天，照片就更不可信了，但奇怪的是，人们明知如此，还是倾向于接受这些图像，甚至对加过滤镜的照片更有亲近感。这是为什么呢？只能说，某种程度上，是游客主动选择了去接受这种幻想。社会又提供了大量专业人士来帮助游客们完善这个过程。专业的商业摄影是制造消费欲望的一大利器，专业摄影师懂得运用一些技术，把照片拍得讲究、好看、有吸引力。商业照片往往更戏剧化、更明亮、更清晰，颜色更饱满，构图也很讲究。它同时要实现几种功能：首先，这些照片得引起游客的兴趣，最好他们看完立马能订机票，动身去照片拍摄地看看；第二，照片要尽量符号化，让他们一眼难忘，照片本身最好取代取景地，成为观看者渴望、回忆的对象；第三，它能提供一些指导，让游客们能够照着再拍一遍。因此，专业摄影好像在替游客以及他们手中的相机写剧本，告诉它们应该怎么看、怎么拍，等游客实际在当地观光旅游时，亲自照着来一遍，就构成了一个循环。也就是说，游客体验到了类似寻宝的快感，还能转而向别人证明：我来过了。当然，商业摄影包含着极大的不真实，虚构性很强，但它擅长制造奇观，它要达成的效果就是好看、动人、震撼。这就需要人们乐意购买它幻想和杜撰的内容，愿意将照片上的东西当真。因此虚构能否产生乐趣，要看人们愿不愿意认真看待幻想。正因为游客愿意参与这种想象，参与对景观的建构过程，一切才运转得起来。摄影于是成为后现代奇观社会的重要一环，它使影像的力量凌驾于现实之上，人们要观看和收集奇观，现实如何则是次要的。消费和制造影像成了要紧事，人们要参与事件，就不由自主地拿起相机。人一旦学会摄影，就变成业余的符号学家和称职的“凝视者”。许多旅游活动实际上只是在寻找好拍的东西，有时观光旅游不过是个途径，积累相片才是真正的目的。照片构成凝视的本质的一大部分，只要能拍出来一张好照片，这个地点就可以变成一个景点，在照片出来的一刻，已经决定了哪里值得旅游，什么画面和记忆可以带回家。就这样，摄影在极大程度上，塑造了旅游和凝视的方式。总结以上就是我们今天要讲的主要内容，下面我们来梳理一下刚才讲到的重点。第一，在现代旅游业的大环境中，游客对特定景观的凝视，是被社会化地建构出来的。游客对于非凡体验的期待和幻想，是推动这种建构的核心要素。第二，旅游业要不断生产和维持凝视的对象才能得到发展，于是便发展出一系列标志性的符号，通过这些符号，来创造和满足游客的幻想和期待。人文景观的消费，往往都挣脱不开这张符号的大网。自然虽提供了山川河流、草木和鸟兽，但人开始有风景意识，再进一步把风景纳入现代旅游凝视的范畴，这是社会发展和观念变迁的结果。第三，旅游经济和旅游文化已经离不开摄影，游客越来越多地通过照片去凝视景观，并且将拍照片和收集照片看作旅游的一大目的，影像在上，现实的重要性反而退居其次了。
