Tim Hardwick:
Apple will bring lossless audio and ulta-low latency audio to AirPods Max in its upcoming iOS 18.4 software update arriving in April, according to the company.
[…]
Apple also said that today it is making a USB-C to 3.5mm audio cable available to buy for $39 from its online store, Apple Store app, and authorized resellers. The cable lets users connect AirPods Max to 3.5mm audio sources like airplane audio ports or connect their iPhone or iPad to speakers or car stereos with 3.5mm inputs.
John Voorhees:
The update will enable 24-bit, 48 kHz lossless audio, which Apple says is supported by over 100 million songs on Apple Music. Using the headphones’ USB-C cable, musicians will enjoy ultra-low latency and lossless audio in their Logic Pro workflows. The USB-C cable will allow them to produce Personalized Spatial Audio, too.
Christina Warren:
As someone who was dumb enough to buy the AirPods Max USB-C edition even after bitching for 4 years about the Lightning Version -- and who had to spend $60 on an AirFly to use it in business class -- this update is overdue but welcome.
Nick Heer:
Allow me to recap the absurd timeline of lossless support for AirPods models.
Steven Aquino:
Whatever Apple’s rationale for the delay, the reason I’m covering the ostensibly esoteric and unrelated bit of AirPods Max news is because it dawned on me while reading Apple’s announcement that I’ve never written about them in an accessibility context.
[…]
A magnetic USB-C port surely would go a long way in shaping an even better user experience for myself (and others).
See also: TidBITS-Talk.
Previously:
Airplane AirPods Audio iOS iOS 18 Mac macOS 15 Sequoia
My Intel MacBook Pro died, and even though I have an M1 MacBookAir ready to replace it, it’s taken several days to get back to the point where I can run older versions of macOS for testing my apps. I had all the old versions installed in separate partitions on an external SSD. Prior to Apple Silicon, I could just plug this drive into a new Mac and continue as if nothing had happened. But Apple Silicon Macs can’t use Intel boot drives, so that won’t work with the new test Mac. Although externally booting Apple Silicon Macs has been a bit dodgy in the past, I figured that 4+ years into the transition the issues had mostly been ironed out. My M1 test Mac already had an external SSD set up with partitions for testing different versions of macOS Sequoia. I figured I could just reformat the other SSD and install fresh copies of all the old versions on it. I eventually succeeded, but the process was anything but straightforward and I’m left feeling like Jeff Johnson:
I don’t understand Macs anymore.
I was already aware of this limitation:
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.
so I created a bootable installer with DropDMG. The main problem I ran into is that, after rebooting and running the installer, a good way into the process it would fail with this error:
com.apple.OSinstallerSetup.error error 702
The detailed error log showed a problem mounting the InstallESDDmg.pkg file: “Couldn't mount dmg! (error code 12).” I searched for the 702 error code and various text from the error log and came up with nothing useful. There are a bunch of pages with generic advice that didn’t apply to me. I’m not using MDM, the Internet connection is working, the clock is correct, there’s plenty of disk space, the installer isn’t damaged, M1 Macs don’t have NVRAM to zap, Find My is disabled, etc.
I tried multiple installers from different major and minor versions of macOS and multiple different destination drives. I tried running the installer with two different Macs, reformatting both the source and destination drives, and repartitioning the destination to have a single partition/container. I kept getting error 702. Both of these Macs had previously successfully created and booted from external drives. What was different now?
I found a promising comment on Howard Oakley’s site:
I tried to install onto an external plugged into the DFU and got a message “The operation couldn’t be completed.(com.apple.OSinstallerSetup.error error 702.)”
I suspect Apple have made a recent change to firmware/hidden volumes which requires the non-DFU port.
This reminded me of one of his earlier posts:
On each Intel Mac with a T2 chip, or Apple silicon Mac, one of its USB-C+Thunderbolt 3 ports is designated for use in DFU mode. That port isn’t labelled, and System Information doesn’t tell you which is the DFU port on that Mac. Instead, Apple lists them for each model here. Beware when reading that support article, as it isn’t internally consistent: for instance, it shows the DFU port as being that on the left of the left side of a MacBook Pro, but states in the text that on a MacBook Pro 14-inch 2024 with an M4 chip, the DFU port is that on the right of the left side instead.
DFU mode is seldom required in T2 or Apple silicon Macs, as it’s how you can refresh or restore the firmware in them. But if you do need to use it, you’ll need to connect a USB-C (not Thunderbolt) cable to the DFU port and perform the procedure from another Mac connected to the other end. However, there is another more common situation in which you need to know the DFU port on an Apple silicon Mac: that’s when you want to create an external bootable disk.
[…]
If the external drive you’re trying to install macOS onto is connected to that Apple silicon Mac’s DFU port, then the procedure is almost certainly doomed to fail. The solution is to connect that external drive to a different port, where it’s likely to succeed.
Apple finally documented this:
If you’re using a Mac with Apple silicon, plug your storage device into any compatible port except the DFU port. Learn how to identify the DFU port. After macOS installation is complete, you can connect your storage device to any compatible port, including the DFU port.
Howard Oakley:
For example, on my Mac mini M4, that’s either the left or right Thunderbolt port, as the middle one is its DFU port. On all other Apple silicon Mac minis, that’s either the centre or right port as you look from the rear, as their DFU port is the one on the left.
[…]
Reformat that disk as you want to use it, with at least one APFS container containing a single APFS volume in regular APFS format (not encrypted).
But, alas, that was not the cause of my problem. Several of the failed installations had been to drives that were not connected to the DFU port.
I did find one other suggestion from Apple:
Reviving or restoring firmware might also help if your Mac experiences a persistent macOS installation error not resolved by other solutions for macOS installation errors.
I was skeptical that reviving would help. It seemed unlikely that both M1 Macs had bad firmware. Restoring an IPSW file for an old version of macOS should definitely work, but I didn’t want to erase either Mac’s internal SSD. And I wanted to install multiple old versions of macOS externally.
But this did give me an idea: could there be something wrong with the recovery partition on the internal SSD? I had noticed something unexpected. Apple says:
On a Mac with Apple silicon:
Recovery installs the current version of the most recently installed macOS.
If you installed a macOS upgrade and then used Disk Utility to erase the disk, you might get the macOS that you were using before upgrading.
I had not erased the disks, but both M1 Macs had Sonoma recovery partitions even though they had been updated to Sequoia. It’s possible to upgrade the recovery partition, but before doing this I figured I should see whether the existing one worked. I might as well try to make a Sonoma boot drive before blowing away the Sonoma recovery partition.
Installing Sonoma from recovery to the external drive worked normally! It then occurred to me that the original 702 error might be related to creating the Ventura recovery partition. But my external drive now had a fresh Sonoma recovery partition. Maybe that would be enough. I added a volume to the SSD and ran the Ventura installer again, and it worked! The Mac could now boot from either Ventura or Sonoma on the external drive. I don’t know whether my analysis is correct, but I tried installing a few more times to prove that it wasn’t something on Apple’s server that had changed. Installing Ventura consistently worked when there was already another version of macOS installed but failed when installing into a fresh drive/container.
I also tried using the DFU port, which isn’t supposed to work, to see what would happen. Installing from recovery to a blank drive said it succeeded, but then booting from the fresh installation failed, saying “Unable to verify startup disk.” However, installing using the DFU port to a drive that already had a bootable partition did work.
More than a dozen installations later, I still don’t fully understand what’s going on here, but I was able to create my external boot drive.
However, around the same time, I discovered a new Mac storage problem, which is that APFS doesn’t seem to be fully backward compatible. I hadn’t read about any problems with this and have in the past used APFS drives formatted from newer versions of macOS on a Mac running macOS 15 Catalina. However, now I have two drives that don’t work on the Catalina Mac. One of them shows up in Disk Utility but doesn’t show the volume’s actual name and doesn’t mount. The other doesn’t show up in Disk Utility at all. Both drives work normally, with the same enclosure, when connected to a Mac with a newer version of macOS. A mystery for another day…
Previously:
Update (2025-03-26): I installed a macOS Sequoia beta on a different external SSD, and this somehow updated the internal recovery partition to Sequoia. Now I am once again getting the 702 error when trying to install a previous version of macOS on an external drive. I can no longer even install Sonoma.
Update (2025-03-27): I used Apple Configurator to restore my M1 MacBook Air to an older version of macOS, in the hope that an older recovery partition would let me install other old macOS versions. Getting the Air into DFU mode took several tries, but I eventually got the timing of the keypresses right. Restoring the Big Sur (11.5) IPSW failed several times with errors such as:
The System cannot be restored on this device.
The operation couldn’t be completed. (AMRestoreErrorDomain error 9 - Failed to receive message from device, might be connection problem with USB host. (Communication error, possibly USB disconnection)) [AMRestoreErrorDomain – 0x9 (9)]
and:
The System cannot be restored on this device.
Failed to restore device in recovery mode, libusbrestore error:21 [com.apple.MobileDevice.MobileRestore – 0x15 (21)]
It had to stay watch on the restore process because otherwise it would be halted when the Mac kept asking for permission to allow the accessory (the Mac being restored) to connect.
I gave up and tried restoring a Monterey IPSW, and that worked the first time.
I was then able to boot from Monterey on the internal SSD and partition an external drive with separate volumes for Big Sur, Monterey, Ventura, Sonoma, and Sequoia.
I installed Big Sur (11.7.10) on the external drive, which succeeded except that when booted from Big Sur it acts as if the Mac has no Wi-Fi. I can enable it in Control Center, but it doesn’t see any networks, and Wi-Fi doesn’t show up in the Network pane of System Preferences. I erased the Big Sur volume and installed it again and got the same problem. Maybe I should try again with 11.6 or something?
Installing Monterey, Ventura, and Sonoma on the external SSD went smoothly.
Update (2025-03-28): Howard Oakley (tweet):
Installing macOS on external bootable disks connected to Apple silicon Macs has been one of the most frustrating experiences of my life, and has driven some more experienced than me to abandon their attempts altogether.
[…]
In each test, I entered the external installer from Recovery mode as detailed by Apple, and started installation to one of the two APFS volumes in the first APFS container on the external SSD. After long periods attempting the installations, both failed with exactly the same error reported by Michael Tsai: com.apple.OSinstallerSetup.error error 702
[…]
I therefore conclude that, in Sequoia 15.3.2 at least, it’s not possible to install any version of macOS prior to Sequoia 15.0 on an external SSD connected to an Apple silicon Mac.
Apple Configurator Apple File System (APFS) Installer Mac macOS 12 Monterey macOS 13 Ventura macOS 15 Sequoia macOS Recovery Storage Thunderbolt USB-C Wi-Fi
Drew DeVault:
Over the past few months, instead of working on our priorities at SourceHut, I have spent anywhere from 20-100% of my time in any given week mitigating hyper-aggressive LLM crawlers at scale.
[…]
If you think these crawlers respect robots.txt then you are several assumptions of good faith removed from reality. These bots crawl everything they can find, robots.txt be damned, including expensive endpoints like git blame, every page of every git log, and every commit in every repo, and they do so using random User-Agents that overlap with end-users and come from tens of thousands of IP addresses – mostly residential, in unrelated subnets, each one making no more than one HTTP request over any time period we tried to measure – actively and maliciously adapting and blending in with end-user traffic and avoiding attempts to characterize their behavior or block their traffic.
We are experiencing dozens of brief outages per week, and I have to review our mitigations several times per day to keep that number from getting any higher.
Via Niccolò Venerandi (via Hacker News):
Then, yesterday morning, KDE GitLab infrastructure was overwhelmed by another AI crawler, with IPs from an Alibaba range; this caused GitLab to be temporarily inaccessible by KDE developers.
I then discovered that, one week ago, an Anime girl started appearing on the GNOME GitLab instance, as the page was loaded. It turns out that it's the default loading page for Anubis, a proof-of-work challenger that blocks AI scrapers that are causing outages.
By now, it should be pretty clear that this is no coincidence. AI scrapers are getting more and more aggressive, and - since FOSS software relies on public collaboration, whereas private companies don't have that requirement - this is putting some extra burden on Open Source communities.
Alex Reisner (via Hacker News, Reddit):
When employees at Meta started developing their flagship AI model, Llama 3, they faced a simple ethical question. The program would need to be trained on a huge amount of high-quality writing to be competitive with products such as ChatGPT, and acquiring all of that text legally could take time. Should they just pirate it instead?
Meta employees spoke with multiple companies about licensing books and research papers, but they weren’t thrilled with their options. This “seems unreasonably expensive,” wrote one research scientist on an internal company chat, in reference to one potential deal, according to court records. A Llama-team senior manager added that this would also be an “incredibly slow” process: “They take like 4+ weeks to deliver data.” In a message found in another legal filing, a director of engineering noted another downside to this approach: “The problem is that people don’t realize that if we license one single book, we won’t be able to lean into fair use strategy,” a reference to a possible legal defense for using copyrighted books to train AI.
Court documents released last night show that the senior manager felt it was “really important for [Meta] to get books ASAP,” as “books are actually more important than web data.” Meta employees turned their attention to Library Genesis, or LibGen, one of the largest of the pirated libraries that circulate online. It currently contains more than 7.5 million books and 81 million research papers. Eventually, the team at Meta got permission from “MZ”—an apparent reference to Meta CEO Mark Zuckerberg—to download and use the data set.
Previously:
Update (2025-03-28): Benj Edwards (via Hacker News):
Software developer Xe Iaso reached a breaking point earlier this year when aggressive AI crawler traffic from Amazon overwhelmed their Git repository service, repeatedly causing instability and downtime. Despite configuring standard defensive measures—adjusting robots.txt, blocking known crawler user-agents, and filtering suspicious traffic—Iaso found that AI crawlers continued evading all attempts to stop them, spoofing user-agents and cycling through residential IP addresses as proxies.
[…]
Kevin Fenzi, a member of the Fedora Pagure project's sysadmin team, reported on his blog that the project had to block all traffic from Brazil after repeated attempts to mitigate bot traffic failed. GNOME GitLab implemented Iaso's "Anubis" system, requiring browsers to solve computational puzzles before accessing content. GNOME sysadmin Bart Piotrowski shared on Mastodon that only about 3.2 percent of requests (2,690 out of 84,056) passed their challenge system, suggesting the vast majority of traffic was automated.
Artificial Intelligence Book Copyright GitLab Lawsuit Legal LLaMA Meta Open-source Software Web Web Crawlers
