macOS Tahoe brings a new disk image format

Disk Image vs Filesystem, and Existing Formats

  • Several comments note confusion in the thread between a disk image format and a filesystem; ASIF is the former, used to virtualize a disk on which APFS (or others) can live.
  • Some argue many “disk image” formats are effectively just sparse files with a mapping table and light metadata; others insist a filesystem-in-a-file is not the same as a proper image/container format.
  • People point to qcow2, VHDX, ISO 9660, UDF, Apple Disk Image, VMDK, and others as examples, but note that specs are often incomplete, proprietary, or drifting from the original documentation.
  • There’s interest in whether ASIF is essentially Apple’s answer to qcow2/VHD, and whether it meaningfully innovates beyond performance tweaks over UDIF.

Desire for Cross-Platform Filesystem Support

  • Multiple commenters wish Apple would invest instead in robust support for ext4, Btrfs, XFS, NTFS, or ZFS, to improve interoperability (e.g., Steam Deck SD cards, external drives).
  • Others counter that no modern, featureful filesystem is truly universal; Linux, BSDs, Windows, and Apple each prioritize their own, and even open-source ones like ext4/Btrfs/ZFS are not broadly standardized.
  • exFAT and FAT32 are seen as the only practical cross-OS choices today, but exFAT’s lack of journaling and FAT32’s 4GB limit are blamed for real-world data loss and workflow pain.
  • Some suggest Apple and Microsoft could cross‑license APFS and NTFS to improve user experience; others are skeptical there’d be agreement on features or incentives.

FSKit and Third‑Party Filesystems on macOS

  • Apple’s FSKit user‑space API is highlighted as a way for third parties to implement filesystems more safely than kernel extensions.
  • Some are wary of trusting third‑party FS implementations with critical data; others note widespread reliance on FUSE, Paragon NTFS, and similar tools, and welcome a safer, supported path.
  • The NTFS3 driver on Linux (by Paragon) is cited as an example of a non‑vendor implementation that eventually became “good enough” for upstream.

Use Cases and Performance: VMs, Containers, Time Machine

  • ASIF is perceived as primarily aimed at virtualization/containers: faster, encrypted sparse-like disk images for VMs and container backends, potentially benefiting Docker for Mac and Apple’s new container APIs.
  • Several users rely heavily on encrypted sparse images for per-directory protection and expect noticeable speedups.
  • There’s interest in how ASIF behaves when stored on NAS (NFS/SMB) and whether it could improve Time Machine or APFS-over-network performance, though this remains unclear.
  • Others note OS updates use different image types, so ASIF likely won’t shrink update sizes.

Apple’s Documentation and Openness

  • Commenters criticize Apple’s tendency to ship new formats without clear public specs, making reverse engineering necessary and interoperability harder.
  • While Darwin source is available, it’s described as messy, poorly documented, and mainly driven by license compliance rather than genuine openness.

HN Meta and Miscellaneous Reactions

  • Some question whether “yet another” disk image format is needed versus reusing VHD/VMDK, suspecting lock‑in.
  • Others see it as an incremental but practical evolution of Apple’s long-standing sparse image/sparsebundle formats.
  • Side discussions touch on HN’s duplicate‑submission rules, the blog’s art content, jokes about the “as-if” name, and speculation (without evidence) about whether these moves hint at future Apple server/cloud ambitions.