A long-standing data corruption bug in ZFS was all over the #zfs news this week. A very good summary is available at FreeBSD Bug 275308 .

TL;DR:

• it's already been fixed and has been merged into FreeBSD stable/14 (and other branches)
• it's also extremely unlikely to have been hitting you if you have ordinary workloads

Just stumbled across this article from 9 years ago: https://betanews.com/2014/01/15/windows-storage-spaces-and-refs-is-it-time-to-ditch-raid-for-good/
NTFS is still the status quo on Windows, believe it or not.

Peter Neubäcker has a stunning Penrose tiling floor on his terrace… I guess now he‘s got to get a new floor though: https://phys.org/news/2023-06-uk-hobbyist-stuns-math-world.html

In case you are making macOS Installer packages and doing that since ages, you should take note of the following passage from the productbuild man page and revisit your Distribution files:

NOTE: On Apple Silicon, the macOS Installer will evaluate the product's distribution under Rosetta 2 unless the arch key includes the arm64 architecture specifier. Some distribution properties may be evaluated differently between Rosetta 2 and native execution, such as the predicate specified by the sysctl-requirements key. If the distribution is evaluated under Rosetta 2, any package scripts inside of product will be executed with Rosetta 2 at install time.

Although it seems awkward at first, this is indeed necessary - any "script" might as well be a binary instead which in turn might require Rosetta 2 (as it's probably not Universal, which is typical for old Installer packages).

In case you're creating the Distribution files manually, the options XML element has a hostArchitectures attribute which lets you specify the exact requirements.

Thanks to Randy Saldinger (Mothers Ruin Software) for letting me know

I just stumbled across the "Unable to enumerate all disks" problem launching a VM on an VMware ESXi host. Looking for the solution to this problem proved inconclusive, but eventually I found both reasons:

• not all delta-chains of snapshotted disks had been properly reassambled!
  • that's probably a bug which was triggered by an after-the-fact setup change done by me (converted disks to independent-persistent after snapshots had taken place). It's probably best to always clone the drives when changing your mind.
• not all snapshot references had been properly cleaned up in the VM's .vmsd file - this also seemingly means that the drive references therein cannot be enumerated!

Note that a vim-cmd -d trivia vmsvc/power.on <vmid> command didn't produce any useful log!