Thanks to Jeff Johnson for pointing out what should have been obvious about the dyld files: they’re compressed (a longstanding feature of Mac file systems which has never been made available to third parties). How many users will simply not update, which surely defeats their whole purpose? Imagine every single Security Update to Big Sur having a minimum size of 3.1 GB on Apple Silicon Macs. Unless Apple improves its design of macOS updates, they will continue to plague those who have upgraded to Big Sur, regardless of whether they upgrade again to Monterey. Whatever the causes of these very large updates, and however much you try to reduce their impact by using the Content Caching Server, they’re more than mere inconvenience to the user. It’s not impossible that some of their content is ‘cloned’ with one another, but that’s not confirmed by their APFS flags. In case you’re thinking that they must be APFS sparse files, the file system doesn’t report them as being regular sparse files, neither are they bundles. ![]() Look at those files, though, and they don’t appear to be that big, each occupying around 1 GB on disk despite a file size of more than double that. ![]() ![]() Each of those is given as being around 2.4 GB in size, meaning that there would appear to be nearly 5 GB of totally redundant dyld shared cache on every Mac running Big Sur. The first thing that strikes you is that every Mac, regardless of its processor, contains three copies of the dyld shared cache for separate processor architectures, x86_64, x86_64h and arm64e. These are assembled in /System/Library/dyld, and behave very oddly. One is the use of cache files for the active contents of Frameworks and Private Frameworks code. Architecture-specific features such as Rosetta 2 are therefore stored on the Data volume, and the System volume contains system files which are common to any and all Macs which can run that version of macOS.īig Sur has also brought internal changes which are widely believed to be important in adding to the size of updates. Rather than have two or more different variants of each release of macOS, Apple’s policy is for there to be just one, with a single Seal for all installations of 11.5.1, for instance. It’s this that appears to account for the difference in size between Intel and M1 Mac updates.īig Sur’s Signed System Volume also plays a part. There’s another quirk too: although the main body of each update, at least 2 GB, is common to both Intel and Apple Silicon architectures, and can be delivered from a Content Caching Server, just over 900 MB has to be downloaded individually to each Apple Silicon Mac at the start of every update, and can’t be cached locally. Executable code doesn’t make up the majority of the system or its updates, but is a substantial proportion. It also means that each update is a Universal binary, containing a complete set of executable code to run native on both Intel and Apple Silicon Macs. Those for Intel Macs amount to more than 600 MB, and that for M1 models must also be substantial, and regardless of which model you’re going to update, the download contains a complete set. Coupled with its policy that only macOS updates can contain firmware updaters, it means that each has to contain a complete set of firmware updates for all supported models. One policy which has led to the inexorable growth in the size of macOS updates is that each is universal: Apple only releases one update, which has to install and update all Macs supported by that version of macOS. So how come it’s necessary to download 2.2-3.1 GB and wait 15 minutes for ‘preparing’ of the update? ![]() As of 11.5.1, M1 Macs have now had over 43 GB of macOS updates, and Monterey must still be at least six weeks away.īig Sur 11.5.1, like 11.2.2 before it, is as minimal as updates get, containing a useful payload of no more than a few megabytes at most. The smallest updates to Mojave and Catalina came in at 1 GB, while 11.5.1 was Big Sur’s smallest yet at more than double that size for an Intel Mac, and triple for an M1 model. What’s most striking isn’t their frequency – 11.5.1 is only the tenth update to Big Sur, the same as in Mojave and less than Catalina’s dozen – but their size. On the other hand, you can almost hear the moans about several gigabytes download and yet another hour or more of installation. On the one hand, we’re all delighted that Apple is fixing bugs and, most important of all, closing security vulnerabilities as soon as it becomes aware of them. Updates to Big Sur have been mixed blessings.
0 Comments
Leave a Reply. |