Kyle Wiggers (OpenAI, Hacker News):
OpenAI says that it will team up with Japanese conglomerate SoftBank and with Oracle, among others, to build multiple data centers for AI in the U.S.
The joint venture, called the Stargate Project, will begin with a large data center project in Texas and eventually expand to other states. The companies expect to commit $100 billion to Stargate initially and pour up to $500 billion into the venture over the next four years.
They promise it will create “hundreds of thousands” of jobs and “secure American leadership in AI.”
[…]
Microsoft is also involved in Stargate as a tech partner. So are Arm and Nvidia.
Previously:
ARM Artificial Intelligence Business Microsoft NVIDIA OpenAI Oracle Web
Jeff Johnson (Mastodon):
In my view, a useful backup system must be (1) chronological, (2) granular, and (3) redundant.
It seems like iOS iCloud backups provide none of these. I thought iCloud Backup used to store multiple backups for each device, and that I could delete older ones to free up space, but now when I go into the settings I don’t see a list of backups, just the date of the “Last Backup.”
The backups are not granular. There’s no way to restore the data for a single app.
Maybe the underlying AWS or Azure storage is geographically redundant, but the most important data like photos and messages aren’t even stored by the backup system. There’s just a single copy of the current data. For most people, the data doesn’t all fit on device so there’s no redundancy that way, either.
iCloud Keychain stores only one version of your passwords, the latest version, so it’s not chronological. You can’t extract a single password from iCloud Keychain without restoring—that is, overwriting—every password, so it’s not granular. And the only way you can restore your iCloud Keychain passwords is via Apple’s online iCloud service, so it’s not redundant. If you lose access to iCloud for some reason, such as an internet outage or an account lockout, or if your iCloud Keychain data becomes corrupted in some way—which happens!—then you’re left with no alternative backup.
I think the fairest way to characterize iCloud Keychain is not as a backup system but rather as a sync system.
[…]
Contrast iCloud Keychain to the login keychain on your Mac. The login keychain is relatively friendly to backup systems. It consists of a single file on disk that can be copied to other disks and read by the Keychain Access app on any Mac, as long as you know the login password. And you can copy individual keychain entries—a password, secure note, key, or certificate—from one keychain to another keychain, using standard copy and paste.
I use iCloud Keychain with Safari AutoFill because it’s so convenient. But, because I have so little control over it, I don’t use it as the primary storage for any of my passwords. It is the only storage for my passkeys, since PasswordWallet doesn’t support them. Hopefully, there will be more tools for this as credential exchange gets implemented.
You can still view your old secure notes in your keychain, but you can’t create new secure notes. Apple wants you to use the Notes app instead. This is extremely inconvenient, for several reasons. I want to manage all of my passwords and secure notes in one place. I need proper backups, but Notes app appears to suffer from the same hostility to backups as Passwords app. And for some reason, unlike the login keychain, locked Notes can’t be locked with your login password unless you enable iCloud Keychain.
Previously:
Apple Password Manager Backup iCloud iCloud Keychain iCloud Photo Library iOS iOS 18 Keychain Mac macOS 15 Sequoia Messages in iCloud Passkeys PasswordWallet
David Smith:
A common point of confusion in Swift Concurrency turns out to actually not be unique to Swift at all: “why can’t you synchronously wait for future async work?”
If you block a thread in your thread pool waiting, a core goes idle, but another one runs the work and unblocks it; not too awful.
What happens if you block all of them? Where does the work they’re waiting for run?
[…]
libdispatch picked “cap at ~64 threads”, which allows misdesigned code to “get away with it” sometimes, at a cost in memory and CPU overhead.
Swift follows the philosophy of “fail fast”: rather than let people write inefficient code that occasionally deadlocks in edge cases, it tries to make people aware of the problem up front.
Rob Napier:
SwiftUI gives us very few affordances for dealing with async state, while actors create lots of it.
So we are now aware of the problem up front, but that “painful rearchitecting” is mostly about dealing with Apple frameworks with little guidance on how to do it.
To solve a problem we never see. (I’m certain Apple sees it regularly at scale, but we don’t.)
[…]
I keep having the situation where I make an actor just to eventually find all of its state wrapped into a single Mutex<State> so that outside things can access it atomically. And I find myself wondering what the actor was supposed to be doing for me and I make it a class again.
Heath Borders:
It’s so easy to say that one should design their systems to be async, but then you run into APIs that require sync answers that you don’t control 🤷🏻♂️
Helge Heß:
I think “indeterminate” would be a better description than “long running”. As long as the locked code makes forward progress and doesn’t wait itself, it should be fine?
David Smith:
So the difficulty we run into is that trying to do it statically (by not providing any APIs to do so), we can’t distinguish between “it’s probably ok” and “not that one”.
But beyond that, I’ve personally been wrong about this. I broke booting iOS with a single spinlock (no priority donation) around three calls to look up the username for a uid, which happened once ever and then were cached. Should have been fine, I thought!
Brendon Justin:
My answer to how I read this question is: blocking a thread on sync IO is safe, even if that’s the last available thread in the thread pool, because the IO has a thread to run on (the current one, since it is a sync call). Whereas blocking on async IO may require another thread be available for said async IO to run on.
Timothy Wood:
NSFileCoordination was … interesting … but one of my favorite bits of using it to write our file syncing thing was the zen of realizing there is no observable current filesystem state, only changes floating in the wind and how you respond as they drift past you.
Marcin Krzyzanowski:
I had 0 bugs
- added async
- added debounce
- I have undefined number of nondeterministic bugs now
Previously:
Concurrency Grand Central Dispatch (GCD) iOS iOS 18 Mac macOS 15 Sequoia Programming Swift Concurrency SwiftUI
Juli Clover (March 2024):
With the App Store and app ecosystem undergoing major changes in the European Union, The Wall Street Journal today shared a profile on App Store chief Phil Schiller, who is responsible for the App Store.
Though Schiller transitioned from marketing chief to “Apple Fellow” in 2020 to take a step back from Apple and spend more time on personal projects and friends, he is reportedly working close to 80 hours a week.
Ben Lovejoy (April 2024):
Phil Schiller has told a court in an antitrust case that he doesn’t know for sure whether the App Store is profitable, and never considered the return on investment when launching it.
He’s also explained the reason that there are very few written records of decisions made around the launch of the store is because Apple co-founder Steve Jobs felt that meeting notes were unnecessary – and the company still doesn’t record minutes for meetings between senior execs …
[…]
“Are you telling His Honour you made the decision without any investigation into what stream of revenue would be produced by imposing a commission of 30 per cent?” Mr Young asked.
“Correct.”
I thought I had already discussed this at the time, but I can’t seem to find the post. I believe Schiller that he doesn’t get a specific report on the App Store’s profitability. What would be the benefit of having an official record? At the same time, surely the numbers are obvious enough that he could say with certainty that it’s profitable.
Ben Lovejoy (Hacker News, Mastodon):
Apple’s incoming CFO didn’t get much time to settle in before he found himself in court defending the company against a class action lawsuit. Kevan Parekh yesterday claimed that the company that it has no clue about its App Store profit margin.
[…]
Apple is facing two lawsuits in the UK, each alleging that the company abuses its monopolistic control over the sale of iPhone apps to charge excessive commissions.
[…]
It’s been independently estimated that Apple’s profit margin on the App Store is in the 75% to 78% range.
An expert witness in the Epic Games lawsuit back in 2019 estimated that the figure was 78%. A British expert in the current case calculated a figure of “more than 75%.”
Parekh told the court that these estimates are not accurate but then pleaded ignorance about what the correct number was.
Tim Sweeney:
Apple and Google make more profit from iOS and Android games than the creators who make the games.
Previously:
Antitrust App Store Apple Australia Business iOS iOS 18 Legal Phil Schiller United Kingdom
