Howard Oakley:
All storage media, including memory, SSDs and rotating hard disks, can develop fragmentation, but most serious attention has been paid to the problem on hard disks. This is because of their electro-mechanical mechanism for seeking to locations on the spinning platter they use for storage. To read a fragmented file sequentially, the read-write head has to keep physically moving to new positions, which takes time and contributes to ageing of the mechanism and eventual failure. Although solid-state media can have slight overhead accessing disparate storage blocks sequentially, this isn’t thought significant and attempts to address that invariably have greater disadvantages.
Fragmentation on hard disks comes in three quite distinct forms: file data across most of the storage, file system metadata, and free space. Different strategies and products have been used to tackle each of those, with varying degrees of success.
[…]
Manually defragging HFS+ hard disks was always a questionable activity, as Apple added background defragmentation to Mac OS X 10.2, released two years before Coriolis was even founded. By El Capitan and Sierra that built-in defragging was highly effective, and the need for manual defragging had almost certainly become a popular myth.
I would agree that defragging became much less useful since the days when I was using the Speed Disk component of Norton Utilities on System 7. But my recollection is that HFS+’s automatic defragmentation didn’t fully solve the problem because it wasn’t able to work on all files (notably skipping large ones, which could have hundreds or even thousands of fragments for a single file) and didn’t consolidate the free space. iDefrag remained useful for spinning disks until the advent of APFS.
APFS also has built-in defragmentation, which in some cases I enabled myself and in other cases seemed to have been automatically enabled. I haven’t noticed any improvement from enabling it, which is unsurprising since Oakley and Mike Bombich say that it doesn’t defragment the file system metadata. APFS performance remains really bad on spinning disks, in my opinion.
Previously:
Apple File System (APFS) DiskWarrior Drive Genius HFS+ History iDefrag Mac macOS 15 Sequoia Storage TechTool Pro
Mario Guzmán (Mastodon):
Customizing an application’s Dock tile when the application itself is not running requires that you write a plug-in. The plug-in’s principal class must implement the NSDockTilePlugIn protocol.
The name of the plugin is indicated by a NSDockTilePlugIn key in the application’s Info.plist file.
The plugin is loaded in a system process at login time or when the application tile is added to the Dock. When the plugin is loaded, the principal class’ implementation of setDockTile(_:) is invoked, passing an NSDockTile for the plug-in to customize. If the principal class implements dockMenu() it is invoked whenever the user causes the application’s dock menu to be shown.
[…]
It is rare to see apps use NSDockTilePlugIn because apps that contain one are not allowed on the Mac App Store.
Previously:
Cocoa Dock Mac Mac App Store Mac OS X 10.5 Leopard macOS 15 Sequoia Open Source Programming Swift Programming Language
Kevin Yank:
When I import a large batch of shots from my camera into Photos, I usually want them in an album, sorted in the order I shot them. The Keep Sorted By Oldest First option would seem to be what I want, but unfortunately its sorting is only based on the capture time of each photo in seconds.
[…]
In order to get the photos into the order I want them, I just need to sort them in the order of their filenames. PA020007.ORF comes after PA020006.ORF, and so on. But Apple Photos can only sort by title, not by filename.
So, to get the sort order I want, I must first assign every photo in the album a title based on its original filename. Of course, typing all these titles in by hand would be impossibly tedious. Thankfully, there’s an open-source tool for that!
Mac macOS 15 Sequoia Photography Photos.app Time
Nick Botticelli (via Hacker News):
Now, to get started, a strategy for approaching the daunting task of running iOS on vma2 is needed. I found the most success with reusing a fully macOS 12.0.1 bootchain and simply replacing the system (OS) image, along with its associated mtree, root_hash, and trustcache files, with that of the iOS 15.0.2’s (iPhone XR build). This would largely bypass the need for (almost) any modifications before iOS initializes, such as to the bootchain and ramdisk (restore process). The XR build was chosen for its arm64e capability and lower-resolution (if that mattered). You should see success with other arm64e device configurations, but do note that the vma2 kernel is hardcoded to return “iPad8,6" for some sysctl key. arm64 versions experienced additional issues and binary incompatibilities, so there is no point in trying these builds.
I used my own fork of tart (a third-party application for managing Apple silicon virtual machines), super-tart for running the iOS VM, which allows for using the required undocumented features provided by Virtualization.framework. I have not yet pushed all of my changes, such as for setting _setProductionModeEnabled(false). Do note that such Virtualization.framework tools that use private APIs require SIP to be turned off, and maybe AMFI as well. I also use my own fork of idevicerestore.
[…]
Getting past the system keybag issues requires many more patches and an understanding of the system as it exists in the iOS system and kernel that I currently lack. This project has already taken at least a few hundred hours of exploration, and I’d be curious to see if anyone can take it further than just booting to PreBoard.app.
Previously:
iOS iOS 15 Mac macOS 12 Monterey Programming Virtualization
