© Kevin Lamarque/Reuters
With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.
A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.
This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.
Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.
Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.
Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.
Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.
Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.
The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.
Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.
This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.
From then onwards, Apple has provided several different presentations of macOS installers and updates:
Loginsoftwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.
macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.
There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).
The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.
This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.
Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.
Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.
macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.
Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.
Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.
With more new M4 Macs in the offing, one question that I’m asked repeatedly is whether you should save money by getting a Mac with the smallest internal SSD and extend that using cheaper external storage. This article considers the pros and cons.
In Apple’s current M4 models, the smallest internal storage on offer is 256 GB. For the great majority, that’s barely adequate if you don’t install any of your own apps. It might suffice in some circumstances, for example if you work largely from shared storage, but for a standalone Mac it won’t be sufficient in five years time. Your starting point should therefore be a minimum of 512 GB internal SSD. Apple’s typical charge for increasing that to 2 TB is around $/€/£ 600.
The alternative to 2 TB internally would be an external 2 TB SSD. Unless you’re prepared to throw it away after three years, you’ll want to choose the most versatile interface that’s also backward compatible. The only choice here is Thunderbolt 5, which currently comes at a small premium over USB4 or Thunderbolt 3. Two TB would currently cost you $/€/£ 380-400, although those prices are likely to reduce in the coming months as TB5 SSDs come into greater supply.
Don’t be tempted to skimp with a USB 3.2 Gen 2 external SSD if that’s going to be your main storage. While it might seem a reasonable economy now, in 3-5 years time you’ll regret it. Besides, it may well have severe limitations in not Trimming as standard, and most don’t support SMART health indicators.
Thus, your expected saving by buying a Mac with only 512 GB internal storage, and providing 2 TB main storage on an external SSD, is around $/€/£ 200-220, and that’s really the only advantage in not paying Apple’s high price for an internal 2 TB SSD.
Upgrading internal storage in an Apple silicon model currently isn’t feasible for most users. As Apple doesn’t support such upgrades, they’re almost certain to invalidate its warranty and any AppleCare+ cover. That could change in the future, at least for some models like the Mac mini and Studio, but I think it unlikely that Apple would ever make an upgrade cheaper than initial purchase.
One of the few compelling reasons for choosing a Mac with minimal internal storage is when it’s going to be started up from an external boot disk. Because Apple silicon Macs must always start their boot process from their internal storage, and that Mac still needs Recovery and other features on its internal SSD, you can’t run entirely from an external SSD, but you could probably get away with the smallest available for its other specifications, either 256 or 512 GB.
Apple silicon Macs are designed to start up and run from their internal storage. Unlike Intel Macs with T2 chips, they will still boot from an external disk with Full Security, but there are several disadvantages in them doing so. Among those are the fact that, on an external boot disk, FileVault encryption isn’t performed in hardware and is inherently less secure, and AI isn’t currently supported when booted from an external disk. Choosing to do that thus involves compromises that you might not want to be stuck with throughout the lifetime of that Mac.
Regardless of the capacity of a Mac’s internal storage, it’s popular to store large media libraries on external storage, and for many that’s essential. This needs to be planned carefully: some libraries are easier to relocate than others, and provision has to be made for their backups. If you use hourly Time Machine backups for your working folders, you’ll probably want to back up external media libraries less frequently, and to different external storage.
Although it remains possible to relocate a user’s entire Home folder to external storage, this seems to have become more tricky in recent versions of macOS. Home folders also contain some of the most active files, particularly those in ~/Library, so moving them to an external SSD is going to require its good performance.
A more flexible alternative is to extend some working folders to external storage, while retaining the Home folder on internal storage. This can fit well with backup schedules, but you will still need to ensure the whole Home folder is backed up sufficiently frequently. This does have an unfortunate side-effect in privacy protection: this may require most of your working apps to be given access to Removable Volumes in the Files & Folders item in Privacy & Security settings. Thankfully, that should only need to be performed once when first using an app with external storage.
When you’re weighing up your options to minimise the size of your new Mac’s internal storage, you also need to allow sufficient free space on each disk. APFS is very different from HFS+ in this respect: on external disks, in particular, HFS+ continues to work happily with just a few MB free, and could be filled almost to capacity. APFS, modern macOS and SSDs don’t work like that.
Measuring how much free space is needed isn’t straightforward either, as macOS trims back on its usage in response to falling free space. Some key features, such as retaining log entries, are sacrificed to allow others to continue. Snapshots can be removed or not made. Perhaps the best measurements come from observing the space requirements of VMs, where total virtual disk space much below 50 GB impairs running of normal functions. That’s the total size of the virtual disk, not the amount of free space, and doesn’t apply when iCloud or AI are enabled.
The other indicator of minimum free space requirements is for successful upgrading of macOS, which appears to be somewhere between 30-40 GB. This makes it preferable to keep an absolute minimum of around 50 GB free at all times. When possible, 100 GB gives more room for comfort.
When the first M1 Macs were released, base models with just 8 GB of memory and 128 GB internal SSDs were most readily available, with custom builds (BTO) following later. As a result, many of those who set out to assess Apple’s new Macs ended up stress-testing those with inadequate memory and storage for the tasks they ran.
Many noticed rapid changes in their SSD wear indicators, and some were getting worryingly close to the end of their expected working life after just three years. Users also reported that SSD performance was falling. The reasons for those are that SSDs work best, age slowest, and remain fastest when they have ample free space. One common rule of thumb is to keep at least 20-25% of SSD capacity as free space, although evidence is largely empirical, and in places confused.
The simplest factor to understand is the effect of SSD size on wear. As the memory in an SSD is expected to last a fixed number of erase-write cycles, all other things being equal, writing and rewriting the same amount of data to a smaller SSD will reach that number more quickly. Thus, in general terms and under the same write load, a 512 GB SSD will last about half as long as a 1 TB SSD.
All other things aren’t equal, though, and that’s where wear levelling and Trim come into play. Without levelling the number of erase-write cycles across all the memory in an SSD, some would reach their limit far sooner than others. To tackle that, SSDs incorporate mechanisms to even out the use of individual memory cells, as wear levelling. The less free space available on an SSD, the less effective wear levelling can be, giving larger SSDs a significant advantage if they also have more free space.
Trimming is performed periodically to allow storage that has already been made available for reuse, for example when a file has been deleted, to be erased and made ready. Both APFS and HFS+ will Trim compatible SSDs when mounting a volume, but Trim support for external SSDs is only provided by default for those with NVMe interfaces, not SATA, and isn’t available for other file systems including ExFAT. Some SSDs may still be able to process available storage in their routine housekeeping, but others won’t. Without Trimming, an SSD gradually fills with unused memory waiting to be erased, and will steadily grind to a halt, with write speeds falling to about 10% of new.
Thus, to ensure optimum performance and working life, SSDs should be as large as possible, with much of their storage kept free. Experience suggests that a healthy amount of free space is 20-50% of their capacity.
Apple silicon Macs work best and fastest when largely running from their internal SSDs. By all means reduce the capacity required by moving more static media libraries, and possibly large working folders, to an external SSD. But there’s no escaping the evidence that your Mac will work best and longest when its internal storage has a minimum of 20% free at all times, and you must ensure that never falls below 50 GB free space. Finally, consider your needs not today, but when you intend replacing that Mac in 3-5 years time, or any savings made now will prove a false economy.
看《波斯语课》，犹太人阴错阳差，靠着教德国军官波斯语来活命，但他完全不会波斯语，于是硬编了一门语言出来，每天编出一些单词让德国人背，犹太人自己也拼命背，忽悠了两年都没穿帮。
这听起来不太可能，当然电影里也做了很多铺垫，譬如犹太人声称自己也不懂读写，只是单纯教口语。在那个信息不流畅的时代，人们对如何学习一门外语的认知，也和我们如今相差甚远。总之，这只是电影里的设定，借此体验剧情就好。
电影的情节，让我想起萨苏说过一个段子：抗战时期的冀中八路军，冒充日本兵去刺探情报，他们只是跟着亲中的日本人学了一阵子口语，就能练到，让日本人听不出是 “外国人在说日语” 的程度。
你们现代人学不好外语，就是少挣俩钱儿。我们学不好的，都牺牲了。
萨苏《尊严不是无代价的》
想象如果换作是我，或者，如果是几个我脑中浮现出的，日常就有压力和情绪状况的朋友，面对这样的情境，这种一旦露馅就会死的巨大压力，能不能蒙混搞定？
大概有人真的会直接选择死亡吧？相比之下，虽然我也焦虑，但默认的思考方向，仍然是先去试试，再大不了一死。虽然自认是语言天赋很糟糕的人，但也存在着微小概率，拼命学外语，然后蒙混过关？——某种意义上，我觉得自己并不是因为面对压力而焕发了斗志，而是，没有经历过这种必须拿命学外语的样子，作为一种体验，有些好奇？
从文化决定论的角度，这些不同的状态，和环境、和文化，有很大的关系。但究竟有多大的关系？古代和如今的环境，对人的影响到底差异在哪里？我并不清楚。甚至，这样的人的比例，古今是否真的不同，现在是否变得更多，我也不清楚。也许他们之前只是没有显现。
以及，我第一次意识到「有的人会在面对巨大生存压力时，直接选择去死」这件事，大概是《大逃杀》里，那几个直接跳崖的学生。
In the elegant simplicity of Classic Mac OS, applications were intended to be single files with much of their contents stored in their resource fork, where they kept all the paraphernalia they required, from code resources to windows, icons and dialogs.
This is QuarkXPress version 4.11 from around 2000, its resources displayed in the resource editor ResEdit. The app icons shown are stored in a resource of type BNDL, a ‘bundle’, but not in the later sense of the term.
In this respect, as in many others, Mac OS X abandoned its Mac past in favour of what had been developed in NeXTSTEP, here a structured directory termed a bundle. These were primarily used for constructs that the user was intended to see as a single item, usually containing executable code and its resources, forming applications, frameworks and plug-ins.
At first, there were two types of bundle in use. Versioned bundles consisted of a file containing executable code, together with a directory containing resources and more directories with further resources, without any Contents directory or top-level property list. New-style bundles contained a minimum of a top-level directory named Contents, and inside that a property list named Info.plist, as continues today. Some implementations of the new-style bundle also contained a file named PkgInfo containing type and creator information that had originated in Classic Mac OS; although apparently not mandatory, PkgInfo has survived to the present in app bundles.
The information property list Info.plist contained key-value pairs in XML format, for attributes such as:
Current bundles are direct descendants of those new-style bundles.
Fat apps with support for both Classic Mac OS and Mac OS X had a more complex structure. Inside their Contents directory, they had the following:
To enable that to run in Mac OS 9, alongside the Contents directory was an alias to the executable code in Contents/MacOSClassic.
The Finder recognised a directory as a bundle and treated it as a single entity if:
Frameworks are an exception to the general rule that the Finder displays bundles as single items, as they are still shown as folders. However, the original reason given by Apple for this, “so that you can browse their header files”, no longer applies.
By 2005, Apple was drawing a distinction between bundles with the formal structure given above, including the Info.plist inside a Contents directory, and other directories presented to the user as a single item, such as RTFD documents, that had different structures and are strictly termed packages. For example, the Rich Text Format Directory (RTFD) favoured by Apple consists of:
This is closer to the versioned bundles of early Mac OS X. Currently, there are distinct UTI types for com.apple.bundle and com.apple.package, with bundles conforming to both, but packages only to the latter. Unfortunately, this distinction between bundles and packages has largely fallen into disuse because of the name collision with Installer packages.
More recently, in its iWork documents, Apple has moved away from plain document packages or bundles to a custom package in a Zip-compressed archive, for example in .pages documents, which still conform to com.apple.package although they can’t be opened in the Finder. Compression has also become popular with space-inefficient formats such as XML.
The introduction of code signing in 2007 brought the requirement to store signature information including code directory hashes (CDHashes) inside the app bundle. This has been implemented using an additional directory, _CodeSignature, containing a CodeResources file. Single-file command tools can instead have their signature embedded in their binary.
Most recently, in 2018, notarization has added the requirement to accommodate its ‘ticket’, which is ‘stapled’ as another CodeResources file inside the Contents directory. However, stapling isn’t required, as notarization can be verified by looking up the CDHashes with Apple’s online service in iCloud. There’s also still no way to staple a notarization ticket to a single-file binary.
The transition from Classic Mac OS to Mac OS X used separate directories for executable code within app bundles, with that named MacOS containing code to be run in Mac OS X. When the Mac architecture changed from PowerPC to Intel, from 32-bit to 64-bit, and again from Intel to Arm, app bundles have continued to use the MacOS directory, with executable code for each supported architecture being saved within each file.
Apple’s Bundle Programming Guide, last updated to 2017
Apple, Inside Mac OS X, System Overview, July 2002, PDF no longer available online.
If you have an Apple device, you’ll be familiar with the idea behind Storage Settings in System Settings > General. What you might not be prepared for is what you’ll see there. Like its equivalent in the General section of the Settings app, the bar chart at the top often shows that much of your Mac’s storage is filled with System Data, and it neither breaks that down into anything more meaningful, nor does it offer a tool to do anything about it.
Storage Settings on macOS has a troubled history. It used to be part of About This Mac, and often took so long to complete its bar chart that folk gave up waiting. In some cases, it even crashed in the process. More often than not, the totals it gave for used and free space on the startup disk were substantially different from those reported by the Finder or Disk Utility.
In recent versions of macOS, Storage Settings has improved steadily. It does now complete its analysis in a reasonable period, and in most cases its figures aren’t too different from Disk Utility’s. But System Data remains a puzzle that confuses rather than enlightens.
From the information given by Apple, it’s most likely that this isn’t really what we’d consider to be data used or required by macOS, but the often substantial difference between how much space is used, and how much can be attributed to other categories, like Books and Music. It’s not a real category, but an etcetera, a ragbag including all sorts of files and other data.
Calculating some of the other categories seems difficult enough. For example, my Music folder contains over 100 GB of individual audio files and my Music library, but Storage Settings recognises less than 50 GB of that in its Music category. The remaining 50 GB has to be accounted for elsewhere, and that’s likely to be buried in System Data. With Photos and TV it’s the other way around, with almost all my libraries stored on an external SSD, but Storage Settings still claims I have 36 GB in TV and doesn’t even mention Photos.
So the categories it does list don’t always match with what we know is on the disk. When it adds all those together and takes that total away from the amount of disk space used, that difference is little more than a guesstimate, and unlikely to contain much data required by macOS. No wonder Storage Settings can’t suggest any way to reduce that size.
Unlike more traditional file systems, APFS is dynamic in its use of storage space, and macOS now uses aggressive caching policies. One of those came to light when we thought the Finder had a large memory leak, only to be told that, in the right circumstances, it can retain GB of Quick Look thumbnails in memory, so that scrolling through them can be smooth. When there’s sufficient free disk space, macOS can maintain large caches without using any swap space on disk.
APFS features like snapshots can retain data we presumed had been deleted, but has to be kept until the snapshot referencing it has been deleted up to 24 hours later. That space has to be accounted for somewhere, and in many cases that too goes into the System Data category, although it has actually been created by Time Machine, which oddly doesn’t have its own category.
Although not given in the Storage bar chart, both the Finder and Disk Utility should state the amount of purgeable space in use. This could be freed when necessary, but that’s determined by macOS rather than the user. I have previously looked at how purgeable some features like snapshots are, and in practice you shouldn’t rely on their automatic removal when you think your Mac needs more free space.
Like its equivalent on iPhones and iPads, some of the tools it provides are of great value in housekeeping. Click on the ⓘ Info button for each of them to get further information and for actions you can take. Categories with the more useful tools include:
Although Music might seem promising, it’s only interested in music video files you can remove.
Don’t trust Storage Settings or the Finder to provide an accurate estimate of free space available on disk. Instead, open Disk Utility (with Show All Devices selected in its view) and in the list at the left in its main window, pick the volume you’re interested in, then go up to its container in the list and select that. Free space shown there is the most accurate estimate of that available to all volumes within that container, as in APFS volumes within the same container all share the same free space.
Select one of those volumes, and you’ll see free space given as a higher value, with a figure for the space that’s purgeable in brackets. That represents the maximum space that could be freed if all purgeable contents were to be deleted.
For example, free space shown here for a container is 619.72 GB, which is the space available without any purging. One volume within that container is given as having 864.5 GB available, with 244.78 GB purgeable:
864.5 = 619.72 + 244.78 GB
Figures given by the Finder are only refreshed periodically, while Disk Utility should recalculate them whenever you select a volume or container, so should always be up to date.
Across much of the temperate parts of the northern hemisphere, this is the wettest part of the year. It’s when puddles are everywhere, and what used to be firm ground turns into soft deep mud. Footpaths and bridleways become deep tracts of mud, impassable in anything but high boots. Yet look through paintings of winter and you’ll notice that few artists before 1800 have depicted people, vehicles or animals in mud of any significant depth. This weekend I look at some of the more faithful accounts of this ingloriously muddy time of year.
In the early nineteenth century, streets in major cities in Europe including Paris spent much of the winter as muddy morasses. Enterprising poorer inhabitants took long planks to locations where the more affluent would try to cross those rivers of mud, and hired them out to enable the rich to stay cleaner.
This is shown well in Louis-Léopold Boilly’s Passer Payez, or Pay to Pass, from about 1803, where a whole family is taking advantage of one of these crossings. This spared their footwear and clothing the otherwise inevitable coating of mud. As you can see, their shoes, lower legs and clothing are amazingly clean, as if they might actually have been painted in Boilly’s studio rather than the muddy streets of Paris.
As realism and real-world scenes became more popular in the middle of the nineteenth century, Adolph von Menzel showed a more accurate view of the problem of muddy roads in his Hussars Rescue a Polish Family from 1850. It had clearly been a wet autumn, with the leaves still burning red and gold on the trees in the background. These mounted soldiers are helping the elderly women from their carriage across the muddy ruts of the road. The hussar in the foreground, with his back to the viewer, even has mud on his riding boots.
One of the first artists to have used mud in a more meaningful way is Jean-Léon Gérôme, in his 1868 painting of The Death of Marshal Ney. Michel Ney (1769-1815) was a leading military commander during the French Revolutionary and Napoleonic Wars, and was made a Marshal of France by Napoleon. Following Napoleon’s defeat and exile in the summer of 1815, Ney was arrested, and tried for treason by the Chamber of Peers. He was found guilty, and executed by firing squad near the Luxembourg Gardens in Paris on 7 December 1815.
Gérôme shows Ney’s body abandoned after the execution, slumped face down and lifeless in the mud, his top hat resting apart at the right edge of the canvas. The firing squad is being marched off, to the left and into the distance. The mud only reinforces Gérôme’s powerful image of a cold, bleak, heartless execution.
Mud also has its recreational uses, as children of all eras will attest. Ludwig Knaus’s painting of Mud Pies from 1873 shows a group of children in the evening, near Dusseldorf, Germany, who are enjoying play in and with the mud, which is less fun for the swineherd behind them.
While other Impressionists had been exploring the effects of transient light on the River Thames, in 1875, Giuseppe De Nittis examined the city’s muddy and rutted streets, in his painting of The Victoria Embankment, London. This wasn’t one of the older roads in the city either: the Victoria Embankment wasn’t constructed until 1865, and had only opened to traffic five years before De Nittis painted it.
Muddy roads in northern British cities like Leeds were one of the favourite settings for the nocturnes of John Atkinson Grimshaw. At The Park Gate from 1878 (above) and November from 1879 (below) are glistening examples.
There’s an old English proverb “February fill dyke, be it black or be it white”, referring to the rain (black) or snow (white) that usually falls heavily during the month and fills all the ditches. Benjamin Williams Leader borrows that in his February Fill Dyke showing the waterlogged countryside near Worcester in 1881.
Mud became a favourite effect in the Naturalist paintings made so popular in France by Jules Bastien-Lepage.
Pas Mèche (Nothing Doing) (1882) shows a cheeky ploughboy equipped with his whip and horn, on his way out to work in the fields. His face is grubby, his clothing frayed, patched, and dirty, and his boots caked in mud.
But for real mud, deep enough for wheels and legs to sink in and cake clothing, I turn to central and eastern Europe.
Jakub Schikaneder’s The Sad Way from 1886 shows a single weary horse towing a cart on which a coffin rests. The woman, presumably widowed before her time, stares emptily at the rutted mud track, as a man walks beside them. It’s late autumn in a world that is barren, bleak, muddy and forlorn.
Józef Marian Chełmoński’s undated Market is one of the most vivid insights into country life in Poland during the late nineteenth and early twentieth centuries. To reach this street market, carts are being drawn through a deep ditch full of muddy water. Market stalls are mounted on tables set in the mud, which forms the basis for everything.
Also undated is contemporary and fellow Polish artist Alfred Wierusz-Kowalski’s Meeting the Train. A couple of horse-drawn carts have gone to a rural railway station to meet a train. The winter snow still covers much of the ground, except where it has been turned into rutted mud on the road.
Had there been opinion pollsters during the eighteenth and nineteenth centuries, no doubt we would have a good idea of the three most popular reasons for moving from the country to towns and cities. Evidence from paintings isn’t always reliable, and depends on the artist’s opinion. However, there are several good indications that I’ll consider here.
Perhaps the most detailed account appears in the many clues in William Hogarth’s opening image in his series A Harlot’s Progress. Sadly, some may have been lost when his original paintings were destroyed by fire in 1755, forcing us to rely on the engravings made of them.
Moll Hackabout, who is about to start her downfall as a harlot, is dressed in her Sunday best, with a fine bonnet and white dress to signify that she’s an innocent country girl. In Moll’s luggage is a symbolic dead goose, suggesting her death from gullibility. The address on a label attached to the dead goose reads “My lofing cosen in Tems Stret in London” (‘My loving cousin in Thames Street in London’), implying that Moll’s move to London has been arranged through intermediaries, who will have profited from her being trafficked into the hands of Elizabeth Needham, a notorious brothel-keeper and madame.
Hogarth thus presents Moll as a gullible victim of human trafficking to supply country-fresh prostitutes for London. Although he did paint a companion series to A Harlot’s Progress involving a man, he didn’t come from the country, so Hogarth sheds no light on the reasons for men and families moving from the country into cities, a theme that doesn’t appear to have been tackled in well-known paintings.
John Roddam Spencer Stanhope’s Robin of Modern Times (1860) is a wide-angle composition set in the rolling countryside of southern England, during the summer. The foreground is filled with a young woman, who is asleep on a grassy bank, her legs akimbo. She wears cheap, bright red beads strung on a necklace, and a floral crown fashioned from daisies is in her right hand. She wears a deep blue dress, with a black cape over it, and the white lace of her petticoat appears just above her left knee. On her feet are bright red socks and black working/walking boots. A couple of small birds are by her, one a red-breasted robin, and there are two rosy apples near her face. In the middle distance, behind the woman’s head, white washing hangs to dry in a small copse. A farm labourer is working with horses in a field, and at the right is a distant farmhouse. This most probably refers to the continuing account of how girls and young women from the country around London found their way to the city to become its prostitutes.
There were other more prosaic reasons that younger people migrated. Among them was a long period of harsh weather, the Little Ice Age, that lasted until the late nineteenth century.
Many British winters featured deep and prolonged snow, even in the south of the country, as shown so well in George Morland’s Winter Landscape with Figures from about 1785. This period was hard enough in towns and cities, but many farms and villages in the country remained isolated for weeks at a time. Even when there wasn’t snow on the ground, there were prolonged droughts and widespread crop failure.
Over this period, staple crops were also changing, with the rising popularity of the potato. Just as rural populations were becoming dependent on the potato, they were struck by the mould causing blight, in 1845. Within a year, much of Europe was suffering failure of the potato crop, leading to death from starvation in about one million in the Great Irish Famine, together with fewer deaths in Scotland and the rest of Europe.
Jules Bastien-Lepage shows the autumn harvest in a more successful year in his October: Potato Gatherers from 1878.
Another sustained pressure on those living in the country was the effect of land enclosure from 1500-1900.
John Crome’s Mousehold Heath, Norwich (c 1818-20) shows the low rolling land to the north-east of the city that had remained open heath and common land until the late eighteenth century. By 1810, much of it had been enclosed and ploughed up for agriculture. Crome opposed the enclosure of common land, and here shows the rich flora and free grazing provided. In the right distance some of the newly created farmland is visible as a contrast.
Enclosure concentrated productive land in the hands of those who owned it, and locked out the poorer labourers who had been reliant on common grazing.
While Britain was spared, across much of Europe the eighteenth and nineteenth centuries saw a succession of wars fought largely in the country. Advancing and retreating armies seized what food they could from farms, and often burned and destroyed what they couldn’t remove.
Once Napoleon’s armies had been defeated at Leipzig in 1813, those of the other countries in Europe pursued them into north-east France, where there was a series of smaller battles and skirmishes fought in the French countryside, amid the terrified farmers and their families. Here Horace Vernet shows soldiers fighting around a burning farmhouse, as its occupants try to escape with little more than their lives. Their cattle are panicking, and it appears that the farmer himself has been shot, perhaps when trying to defend his family. A small boy buries his head into his mother’s apron.
As a result of those pressures, whole families abandoned their relatives, often those who were older and less likely to make a successful living in the city, and went to live in the growing towns and cities.
Erik Henningsen’s painted record of Farmers in the Capital from 1887 is one of few contemporary accounts. This family group consists of an older man, the head of household, two younger women, and a young boy. Everyone else is wearing smart leather shoes or boots, but these four are still wearing filthy wooden clogs, with tattered and patched clothing. The two men are carrying a large chest containing the family’s worldly goods, and beside them is their farm dog. The father is speaking to a mounted policeman, presumably asking him for directions to their lodgings.
The large brick building in the background is the second version of Copenhagen’s main railway station, opened in 1864, and replaced by the modern station in 1911. This demonstrates another significant factor in the attraction of people to towns and cities: the spread of railways across Europe.
It might seem strange today, but for much of the early history of the Mac we used printed manuals and books. For developers the reference was Apple’s Inside Macintosh series, lovingly crafted by its technical authors using Microsoft Word and published by Addison-Wesley. Even Aperture (2005) and Apple’s Pro apps like DVD Studio Pro 3 (2004) came with beautifully prepared and printed manuals.
It was the introduction of Apple’s first CD-ROM drive in 1988 and its subsequent release of the first developer CD, Phil and Dave’s Excellent CD the following year that started change. At first there was a battle between nascent common document formats, including Adobe’s Acrobat, Farallon Replica, DjVu and others. In the early 1990s this led to HTML-based help books, and printed manuals became gradually replaced by electronic documentation.
Unix had a longer evolution, with the first of many man pages written for formatting using nroff in 1971. Although printed references were published later, deep piles of fanfold printout remained popular long after the rest of computing had discovered the value of desktop publishing. While much reference material was still confined to source code files, brief glimpses into how to use commands are still revealed in lightly formatted text man pages.
The release of Mac OS X 10.0 brought with it a primary help system, Apple Help, as part of Cocoa. Those creating help books wrote them in HTML saved in a folder structure like a local website, and a cut-down browser Help Viewer displayed them for the user. The only detailed account of this, the Apple Help Programming Guide, was first published in 2003, and last revised a decade later, 12 years ago.
Help Viewer started with a spartan interface, here in 2004, and relied primarily on pages stored in local help books.
Help books can contain localised versions to support their use worldwide.
Although seldom used, you could build your own custom help book, as shown in this demonstration I created for the UK magazine MacUser in 2006.
Apple reserved /Library/Documentation/Help and its sibling in the user’s Home library for its own use, and from OS X 10.6 third-party help books were expected to be stored as a .help bundle in the Resources folder in an app’s bundle. HelpViewer.app was hidden away in /System/Library/CoreServices, and helpd was an on-demand service to watch Applications and Utilities folders for newly-added apps containing help bundles, and register them with macOS.
By 2017, HelpViewer’s toolbar offered Back and Forward buttons, a button to hide or show the sidebar, and one to share the current page.
Searching help was aided by an index built by Help Indexer during authoring (below, from 2006), and used Spotlight’s local search powers.
Unfortunately, help became neglected and started to deteriorate. During macOS High Sierra 10.13 to 10.13.4, it was revised internally, and the way that helpd worked was improved.
The macOS help system had previously relied on the user (or an installer) adding an app bundle to one of its two watched folders, /Applications and /Applications/Utilities, to trigger the process of adding any new or updated help book to those available. The helpd service was activated by File System Events when such an event occurred, and responded by checking the app bundle for a help book to register it. If an app was installed in another folder, even ~/Applications, then its help book might not get registered properly.
Identification of help books also changed. Previously, that for the Dictionary app was known as com.apple.Dictionary.help, making it difficult to accommodate more than one version of an app and its help book at a time. The new system incorporated a version number, such as com.apple.Dictionary.help*2.2.2.
When originally developed, the great majority of help books relied on static content built into them. All that had to happen for most was the launch of HelpViewer, and for it to open the supplied Help book.
Since then, help books had increasingly relied on online content, which needed to be refreshed before each access. Thus HelpViewer and helpd had to work together to deliver the latest content, with helpd doing the refreshing and updating to the databases in ~/Library/Caches/com.apple.helpd, which HelpViewer used with the WebCore rendering engine to display pages and interact with the user.
Since then further bugs have come and gone; among the more troublesome were those in Big Sur and Monterey, that could prevent a Help book from opening, or, if it did eventually open, the book displayed completely blank pages.
It also had some more amusing moments, including a phase in which the help system decided that I wanted to read Apple Configurator’s help book in French.
For Ventura, Apple revised the help system further, and renamed HelpViewer to Tips while keeping its formal identifier as com.apple.helpviewer, and it remained hidden away in CoreServices. In Sequoia, it leapt from version 10 to 15 and joined Apple’s first league apps between Time Machine and TV in the main Applications folder. But if you want to read the documentation for any command tool, you still have to refer to its man page.
Although your Mac’s boot volume group, including the Data volume that’s almost always used for your Home folder, has to be in APFS format, you can still use Macintosh Extended or HFS+ format for other drives and their contents. This article provides advice to help you choose between the two Mac native file systems.
Other than the boot volume group, including the Data volume, APFS is only likely to be required to store Time Machine backups in recent versions of macOS. Although I think it’s still possible to continue backing up to an existing HFS+ backup store, you should stick to APFS for all new Time Machine backups.
One possible let-out, used for network backups, is to host a sparse bundle on another file system, and for that to use APFS internally. That’s how NAS can host Time Machine backups on Linux file systems such as Ext4 or Btrfs. However, I wouldn’t recommend putting that sparse bundle on HFS+, where they have known problems.
All new local Time Machine backups for recent macOS should be to Case-sensitive APFS, either encrypted or unencrypted.
There are two types of file that are special to APFS and don’t exist in HFS+. Although they also exist in some other modern file systems, they can’t generally be converted between those and APFS.
Most modern file systems store files that contain significant amounts of blank or absent data in a special sparse file format. In APFS, this is implemented by only allocating file extents to those blocks that do contain data. In many cases, this can save significant disk space. Initially, sparse files were unusual in APFS, but over time they have become increasingly common, and can now be found in some types of disk image, virtual machine storage (VMs), and in databases. Note that disk image types whose name includes the word sparse, sparse bundles and sparse disk images, don’t use sparse file format at all, but are the victims of an unfortunate name collision.
Neither macOS nor APFS can simply convert regular files to sparse format; for a file to be written in sparse format, the code writing it must explicitly skip the empty space. As a result, sparse files are prone to explode to full size when they’re copied or moved unless that’s between two local volumes both using APFS. Examples of where you should expect them to explode include:
In each of those cases, sparse files explode in size as they’re copied from the source volume. If you have a 100 GB sparse file that only takes 20 GB of local disk space, when it’s copied to a local HFS+ volume, the full 100 GB has to be transferred.
One potential workaround is to compress the sparse file before transferring it. All good compression algorithms will work efficiently on the blank space in the file, so when compressed its size could be as small as the original sparse file. However, when it’s decompressed, even on another APFS volume, it will explode to full size. For disk images, that can be corrected by mounting them, as APFS will then trim their contents, and the disk image should be saved back into sparse format.
These are two distinct files that share common data, normally the result of duplicating the original within the same APFS volume. Those two cloned files then only require the storage of the whole file, plus those data blocks that differ between them. This only works within the same volume, and the moment that either of the clones is moved or copied to any other volume, it assumes full size, as it can no longer share data with the other clone. Clones can’t span two volumes.
However, most other file systems don’t support file cloning in this way. When you duplicate a file in an HFS+ volume, there’s no shared data between them, and the two require twice the amount of space as one.
In terms of disk space used, the benefits of sparse and clone files aren’t as obvious as you might expect. Because of their potential to swell to full size, sparse files can’t be copied to a volume that isn’t large enough to cope with that, but once they have been copied they only require their current size on disk.
As far as you’re concerned, greatest benefits come in speed of handling, and effects on SSD ‘wear’. Creating clone files is almost instant, even if they’re huge, and because of their efficiency in the use of storage extents they minimise erase-write cycles on SSDs.
I have recently explained how snapshots work, and how you can use them alongside proper backups to restore lost or damaged files. Snapshots are used in most modern file systems, but don’t exist in HFS+. If you want local snapshots of any volume connected to your Mac, you’ll most likely have to use APFS unless you know how to use something more exotic. Note that, unless you’re Time Machine, you can’t copy snapshots to another volume or drive, but you can mount them and copy their contents to another volume.
Unlike HFS+, APFS was designed with encryption built in. This significantly improves its performance with encrypted volumes, and makes them more secure. If you need to store files in an encrypted volume, you should prefer APFS for that volume.
In HFS+, volumes have fixed size, as they’re disk partitions. Although you may be able to change partitioning that’s already in use without losing data from any of the volumes involved, that’s never guaranteed.
In APFS, volumes share free space with others within the same container. While you can set limits on individual volume size, this makes management of free space much easier, allowing volumes to occupy the space they require, instead of that being predetermined.
These aren’t available in APFS, but are supported in HFS+, where they’re used extensively in old-format Time Machine backups. They work like regular hard links, but act on directories rather than individual files. They can’t be copied in any way to an APFS volume, but can be used to reconstitute a volume. This ensures a new Mac that only uses APFS can still access old Time Machine backups from a previous Mac: macOS retains full support for HFS+ and its directory hard links, so you can mount those old backups and access them through the Finder.
APFS was designed for use on SSDs and the Flash drives used in Apple’s devices. It has design features that will never work well on hard disks, as they fragment not only file data, but the file system itself. While it’s possible to boot an Apple silicon Mac from a hard drive, you wouldn’t want to run your Mac from one. With an active file system such as that on your Mac’s Data volume, files and the file system get steadily more fragmented until the drive eventually grinds to a halt.
Hard disks using APFS normally remain usable for a year or more when they store files that don’t get changed very often, like media libraries, and in many cases backups, including Time Machine’s. Experience with the latter suggests that most cope well, but in extended use they too eventually become too fragmented to continue. There currently isn’t any effective solution to that fragmentation, other than wiping the volume and starting from scratch. Because Time Machine’s backups are stored as snapshots, they can’t even be copied to another drive to help.
APFS has been designed to be far more robust and reliable than HFS+. A longstanding problem with HFS+ before journalling was introduced was its propensity to accumulate minor errors that eventually lead to catastrophic failure. One common reason for this was sudden restarting or other interruptions to file system operations. Journalling was added to reduce the chances of those leading to file system damage or inconsistency, and for that reason, you should never use HFS+ without journalling.
One key feature in APFS that makes errors highly improbable is its use of copy-on-write for all file system metadata. This ensures that changes made to the file system are almost guaranteed to remain consistent, even when suddenly interrupted. Unfortunately, one of the side-effects of copy-on-write is fragmentation of file system metadata, thus its main limitation on hard drives.
If your Mac is running a more recent version of macOS, from Mojave onwards, all its SSDs should by default use APFS. Deciding which to use for hard disks is more difficult, and you need to weigh up their advantages and disadvantages carefully. Unless the volumes on that disk are going to see frequent changes, when fragmentation could result in poor performance, in most cases APFS should now be the default.
HFS+
Inside the file system: 1 Disks and partitions
Inside the file system: 2 HFS+ volumes
Inside the file system: 4 Summary and references
APFS
APFS: Files and clones
APFS: Directories and names
APFS: Containers and volumes
APFS: Snapshots
APFS: Encryption and sealing
APFS: Special file types
APFS: Command tools
APFS: Beyond, to vfs and volfs
APFS: Log entries
APFS: Extended attributes revisited
APFS: How sparse files work
（Abstract）因为汉字圈的外国人在日本既有可能使用护照上的英文名，也可能使用汉字名，而读音又各不相同，于是就会出现各种五花八门的组合。 
（Abstract）这个网站的特殊之处在于：第一、每首诗都有相应的古籍文件对应。第二、尽可能把异文收集完整了。一半以上的古诗都有多个版本。 之前聊到，日文、藏文的语序结构，和我们习惯的中文、英文不同，是谓语动词放在句子最后的「主语-宾语-谓语」的形式。
：（吐槽）所以人们常说的，日本人懂礼貌，会听人把话说完。其实是因为这样的结构，需要认真听到最后一个词，才知道整个句子要说「是」或「不是」啊。
：对于需要使用不同敬语的日本人，也方便他们先把宾语对象列出来，再根据其身份，决定用什么样的敬语去修饰动词。
另一个 blog 有时候写得少的原因，大概是在「文章是在写给谁？」这方面，无意识地发生了混乱。
除去一部分
的篇目；其它很多文章，应该是（有意识或无意识地）有一个，潜在的写作对象的。他可能是
于是，经常写到一半，突然意识到这个对象的存在，然后陷入「我这样写，有什么意义吗」的沮丧，也就不写了。
又或者，吐槽吐到一半，突然意识到，我所吐槽的特质，其实和来看 blog 的人，并不相关。于是反而担心，会不会让读者们对号入座产生误解，或者觉得我这个对空掰扯道理的样子很爹味儿之类的。
——就像在「主-宾-谓」的句子里，谓语写一半了，才意识到，那个预设的宾语的存在。
（Abstract）《Long, Long Ago》是 1883 年英国作曲家创作的歌曲。目前经常有纯音乐用于儿童钢琴曲或婴儿催眠曲，也有英文唱词。然而上世纪 90 年代初它有中文唱词，目前已“失传”。 