Archive for June 4, 2024

Tuesday, June 4, 2024

macOS Installer’s “Failed to Personalize” Error

Adam Engst:

Typically, Mac firmware is updated whenever a new version of macOS is installed, but if something goes wrong in the process, the Mac can be left with outdated firmware. When automatic firmware updates fail, the solution is to “revive” or “restore” the Mac using another Mac running macOS 12 Monterey or later and a USB-C cable that supports data and charging, such as the Apple USB-C Charge Cable (Apple explicitly warns against trying to use a Thunderbolt 3 cable). Although Macs running Sonoma can update firmware using the Finder, Apple Configurator is necessary for Macs running Monterey or Ventura, and LALicata’s Apple rep said that this particular problem could be resolved only by restoring from Apple Configurator, not the Finder. (Reviving leaves your data in place and is worth trying first; restoring erases the Mac and reverts it to factory defaults.)

[…]

If you’re having problems associated with startup or updating, compare your Mac’s current firmware version with the latest version. Howard Oakley’s excellent Silent Knight utility, which reports on the update status of various system settings, makes that easier.

[…]

I’d argue that the problem here revolves around documentation. First, the error message is terrible. What does “Failed to personalize” mean (nothing, in at least this context, and not much in any I can imagine), and how is it related to firmware (it’s not)? […] The error condition might be rare, but it’s not unheard of, so the second problem is that Apple’s article about reviving and restoring Mac firmware doesn’t include the error message text as one of the symptoms of corrupted firmware.

Previously:

Update (2024-06-06): Paul Goracke:

I had to DFU revive to fix an even more generic install error. Unfortunately, it seems I need to do it again to update to 14.5 😭

Proposed EU Chat Control

Patrick Breyer (via Hacker News):

The highly controversial indiscriminate child sexual abuse regulation (so-called chat control) could still be endorsed by EU governments after all, as France could give up its previous veto. This is reported by Euractiv and confirmed by internal documents. France considers the new “upload moderation” proposal in principle as a viable option.

[…]

[Users] of apps and services with chat functions are to be asked whether they accept the indiscriminate and error-prone scanning and possibly reporting of their privately shared images, photos and videos. Previously unknown images and videos are also to be scrutinised using “artificial intelligence” technology. If a user refuses the scanning, they would be blocked from sending or receiving images, photos, videos and links (Article 10). End-to-end encrypted services such as Whatsapp or Signal would have to implement the automated searches “prior to transmission” of a message (so-called client-side scanning, Article 10a).

[…]

Probably as a concession to France, the chats of employees of security authorities and the military are also to be exempted from chat control.

This is kind of like what Apple was planning to do with iMessage, using AI rather than just checking for known images, but:

Meredith Whittaker:

Signal strongly opposes this proposal.

Let there be no doubt: we will leave the EU market rather than undermine our privacy guarantees.

This proposal--if passed and enforced against us--would require us to make this choice.

It’s surveillance wine in safety bottles.

Previously:

Update (2024-06-18): Alexander Martin:

Meredith Whittaker — president of the Signal Foundation, which operates the end-to-end encrypted (E2EE) messaging app of the same name — criticized on Monday the latest European Union proposals for requiring messaging services to check if users were sharing child abuse material.

Her complaint follows the publication of an internal document from the European Council — the EU body that sets the bloc’s political direction — revealing its position as of the end of May on a proposed regulation to “prevent and combat child sexual abuse.”

Matthew Green:

The European Council has taken a proposal to force mandatory scanning of all photos and videos sent through private messengers (including encrypted messengers like Signal) and they’ve rebranded it as “upload moderation.” The implication is that it’s voluntary when it’s not.

If you choose not to submit your deeply private personal photos to be scanned for criminal activity, you won’t be allowed to send images or videos at all. It’s coercion into a mass surveillance regime, with some branding.

And if your reaction is “oh well at least it’s just images and not the private text messages themselves,” understand that this is a temporary climbdown from the original proposal that required AI scanning of text messages as well. This proposal is an obvious stepping stone.

It’s not clear how this can be done safely for encrypted messengers, or if it can be done at all. None of the people behind this proposal have any idea. Their plan appears to be: get the law in place and then it won’t really matter.

Update (2024-06-20): Patrick Breyer (via Hacker News):

This is what the current proposal actually entails[…]

Meredith Whittaker (via Hacker News):

Official statement: the new EU chat controls proposal for mass scanning is the same old surveillance with new branding.

Whether you call it a backdoor, a front door, or “upload moderation” it undermines encryption & creates significant vulnerabilities.

Proton:

“The fact that the EU interior ministers want to exempt police officers, soldiers, intelligence officers and even themselves from chat control scanning proves that they know exactly just how unreliable and dangerous the snooping algorithms are that they want to unleash on us citizens.”

Matthew Green:

People think ChatControl is about specific crimes. No, that’s not what’s at stake. What’s being made is an architecture decision for how private messaging systems work : if it passes, by law these systems will be wired for mass surveillance. This can be used for any purpose.

Once you build an architecture where every interpersonal private message goes through a scanning filter, one that reports to the police, the only question in the future is: what software updates do you push to that filter?

Alex Ivanovs (via Hacker News):

The EU Council and its participants have decided to withdraw the vote on the contentious Chat Control plan proposed by Belgium, the current EU President.

Update (2024-06-24): Nick Heer:

That is a truncated history of this piece of legislation: regulators want platform operators to detect and report CSAM; platforms and experts say that will conflict with security and privacy promises, even if media is scanned prior to encryption. This proposal may be specific to the E.U., but you can find similar plans to curtail or invalidate end-to-end encryption around the world[…]

Update (2024-09-17): Sebastiaan de With:

With Thierry Breton’s resignation the European Commission loses one of the most fierce proponents of ChatControl, their longtime effort to weaken or eliminate secure online communications, and regulatory overreach.

As a European I am genuinely relieved to see him gone, though I still fear there’s a lot of powerful forces trying to get it pushed through.

Previously:

Update (2024-09-19): Nick Heer:

This [new proposal] is a similar effort to that postponed earlier this year. The proposal (PDF) has several changes, but it still appears to poke holes in end-to-end encryption, and require providers to detect possible known CSAM before it is sent. A noble effort, absolutely, but also one which fundamentally upsets the privacy of one-on-one communications to restrict its abuse by a few.

Swift at 10

Basic Apple Guy:

10 Years Ago: Apple Announced Swift

Brian Webster:

10 year anniversary of Swift being announced at WWDC.

Chris Lattner:

Wow that’s right. This was a big day and Swift has come a long way in the intervening decade: Congrats to everyone who has driven it forward to support such an amazing tech platform! 🍎🐣

Jim Rea:

Interesting to go back and watch this presentation and see how Swift was originally promoted ten years ago. I would certainly say that Swift has been a huge success. On the other hand, I’m personally still 100% programming in Objective-C and that continues to be an excellent development environment for building a sophisticated Mac app.

My high-level take is that I generally like programming in Swift. I’m rewriting all my apps in it. But I’m not sure it was the right thing to build. It’s been such an immense effort both within Apple and for the community. This has been a distraction from apps, frameworks, architecture, and documentation. So much mindshare has been taken up by the language itself, which should be just a tool for building the things that actually matter for our customers. It’s come a long way, but the “end” is not yet in sight, as, even 10 years in, essential pieces are still being designed.

I think it’s quite possible that most of the parts that I, as an app developer, care about could have been had—sooner, and with greater tools speed and reliability—with a less ambitious project that actually tried to be Objective-C without the C, rather than a more static mega language that tries to replace C, C++, Objective-C, and Rust. The question is not how Swift 5.10 compares with Objective-C 2 but how it would compare with the hypothetical Objective-C n or Objective-Mojo that we could have had instead.

It all comes down to the big vision of world domination and having a single language from the bottom of the stack to the top. That would never have happened with a more pragmatic evolution of Objective-C. If that eventually pans out, and Swift ends up being good at all levels of the stack, that would be a triumph. But, here in 2024, it still seems like a very long way away. In another 10 years, I suspect that XNU and WebKit will still be mostly C and C++, and the app frameworks will still have large amounts of Objective-C (or C++ in the case of SwiftUI).

Now let’s look at some specifics. The good:

The bad:

Previously:

Update (2024-06-05): See also: Hacker News.

Der Teilweise:

I’d say what I like most about Swift is Optional. It is simple to use (especially since we got if let x {}) but gives one a warm feeling of not missing a nil.

I 100% agree with each and every point in the bad list.

Thinking of integer index for string, I’d add a “Stubbornness of the language guardians” (phrased as “Strict adherence to a clean design.”) but I do not disagree with any of the points that are on the list.

Damien Petrilli:

I agree with Michael’s take but to me the jury is still out on performance. It’s clearly not competitive against C++.

Update (2024-06-06): See also: this Swift roast and Nathan Manceaux-Panot.

Francisco Tolmasky:

Swift is 10. I think at 7 or so I asked whether it felt it was as mature as ObjC/Cocoa were at that age. I have a different question now. Where do we think Swift will be in 10 years? Will SwiftUI actually be capable of making a real Mac app? Or will we have a new language and/or framework by then (20 years after Swift). Or will the Mac maybe just no longer exist by then, making this question moot?

Kyle Howells:

There’s 2 separate worlds of software development.

Building apps and user facing features.

Infrastructure and low level language design.

Swift concurrency (and a lot of Swift actually) just looks to me like evidence the language people being given far too much power, to run away with architecture astronauting projects.

Sarah Reichelt:

Apple banning employees from developing their own apps has many negative effects and this is one of them.

Alex Grebenyuk:

The parts of Swift Concurrency that make me more productive when building apps are Async/Await and maybe MainActor. Everything else is more work for little benefit, making it impractical.

Update (2024-06-07): See also: Reddit and Lobsters.

Steve Streza:

  • The language delivered on core promises of better architecture, reduced crashes, more semantic types
  • The compiler is simply not adequate, it is barely functional and Apple has failed to invest in it sufficiently
  • Initiatives like WASM, server-side are exciting but hamstrung by the BDFL problem making it difficult to widen the ecosystem like in Rust, JavaScript, etc
  • Swift is still just “the language for Apple dev”, not a true C-level player like Rust

Update (2024-06-19): Andy Finnell:

After 10 years of Swift, I still get compiler crashes on the regular. Xcode should at least make them actionable.

The compiler logs give instructions on how to file a bug report. It should just be a button I can press.

The compiler logs give zero indication of what’s causing the crash. Xcode should have a command that runs a bisect over the file causing the crash until it’s identified the offending lines. i.e. automate what a human would do by commenting out code.

Daniel Hooper (via Hacker News):

The Swift compiler can take an absurdly long time to compile expressions due to how types are inferred. Here’s an explanation by the creator of Swift, Chris Lattner (from from his Mojo talk [Hacker News] and edited for clarity):

My experience with Swift is we tried to make a really fancy bi-directional Hindley-Milner type checker and it’s really great because you can have very beautiful minimal syntax but the problem is that A) compile times are really bad (particularly if you have complicated expressions) and B) the error messages are awful because now you have a global constraint system and when something goes wrong you have to infer what happened and the user can’t know that something over there made it so something over here can’t type check. In my experience it sounds great but it doesn’t work super well.

[…]

Swift 6 spends 42 seconds on these 12 lines on an M1 Pro, only to spit out the notorious error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions. In the same amount of time, Clang can perform a clean build of my 59,000 line C project 38 times. The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.

Even very short snippets of code can trigger that error message, and compilation is also slow even for code that doesn’t trigger it.

Steve Troughton-Smith:

People seem to be blissfully unaware of just how many resources go into making yearly OS updates happen. An anecdatapoint I’ve heard thrown around is that the introduction of Swift into Apple’s codebases more than doubled the time it takes to build all of Apple’s OSes every night across their build farms, to the point where it now takes a day and a half to run a ‘nightly’ build.

Marcel Weiher:

Scrub a little earlier for more details on the problems with unpredictable performance.

Ben Cohen:

In May 2015 (so still in the Swift 1 days) I wrote a version of Peter Norvig’s simple spelling correction generator. I happened to think of it again and thought I’d try updating it to use all the improvements to Swift that have happened since then.

See also: Reddit, The Talk Show.

Update (2024-06-25): See also: Hacker News.

christophilus:

Ocaml is really fast to compile when I play with toy projects. It’s a fairly simple type system compared to, say, TypeScript (I’m not familiar enough with Swift to know how it compares to Ocaml in terms of type system complexity). I’d prefer the simpler language if it means faster compilation.

Helge Heß:

My protobuf schema now needs ~30 seconds to compile on the Swift side.⏳

Update (2024-07-15): Chris Lattner discusses progressive disclosure and Swift’s complexity (via Hacker News):

Swift, the original idea was factor complexity (…) massively failed, in my opinion (…) Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff

[…]

instead of fixing the core, what the team did, both when I was there, so partially my fault, but also subsequently, is they started adding all these special cases (…) a lot of this stuff got added under extreme time pressure to enable a feature like SwiftUI. And there’s a bunch of stuff that feeds into that, as well as just the language gets more and more and more and more complicated.

Update (2024-09-23): Chris Lattner:

Great to dive into PL with Richard, a legit language implementer! We explored a wide range of topics, incl lessons learned Swift=>Mojo, how the structure of integer types + overflow is more complex than it might look, approaches to safety, acceleration of novel HW with Mojo etc.

He talks about design decisions that led to Swift’s type checking being slow and its error messages being unhelpful, and how Mojo avoids these problems. Mojo also has much more limited support for custom operators because the fancy system developed for Swift ended up not getting much use to justify the complexity.

Sebastián Benítez:

After using Swift for more than 5 years I can confidently say that it’s getting worse with each addition, very similar to how C++ ended up being the monster it is. In comparison, Objective-C is simpler, somewhat minimalistic, and yet it did a great job for many Mac developers for a long time. I’ve heard that Swift code leads to less crashes and better performance, but that’s not what I’ve experienced. Well written Objective-C code can be easy to understand as much as well written Swift code. But overly complex Swift code is much more difficult to maintain and understand than similar Objective-C code.

SwiftData Issues in macOS 14 and iOS 17

Helge Heß:

Ugh, inverse SwiftData relationship updates do not seem to trigger Observation, that feels like a biggie 😳

[…]

This feels really bad, because the relationships are the thing which make an ORM worthwhile. I.e. you’d usually have a network of many objects being displayed in distinct views (not just the simple demo). Those will lack updates as connections change.

[…]

As far as I can tell CoreData does the right thing here and updates the inverse properly.

Tony Arnold:

SwiftData’s ModelContext.didSave and ModelContext.willSave don’t actually work in any current OS release, do they? FB13509149

Jon Duenas:

Trying to build a SwiftData predicate with even the slightest bit of complexity is a nightmare. I only have 4 properties to filter on and the compiler completely chokes when building the macro.

Tony Arnold:

Has anyone had much luck with non-optional one-to-many relationships in SwiftData?

[…]

I have the setup working, but I need to decode and insert the User entities prior to decoding and inserting the Place entities (and save!) so that I can lookup an existing User entity each time I decode and insert a new set of Places.

It seems like more effort than the rest of the framework would suggest is necessary.

Paul Darcey:

Yeah, it’s non-intuitive - you have to do it what I think of as “the wrong way around.”

Decode and initialise your User, but don’t insert it yet!

Decode and initialise your Place(s), and use the just-initialised User as the user for those Places

Then insert the Place(s).

Senor Ganso:

What I found is SwiftData is really finicky about relationships. The only reliable way is to make all of them optional, then first insert the base model and only the add the related models to it (preferably inserting them first too).

Helge Heß:

A SwiftData PersistentModel class stores the actual property data in an opaque BackingData thing which is created with the model. The interesting thing is that this seems to require a ModelContainer existing “somewhere” that has the model registered already.

[…]

Using the same type in multiple containers may be an antipattern. Though it shouldn’t be, they are global types.

I’m already running into crashes seemingly related to this in my test suite.

Sixten Otto:

I encountered this just a couple of days ago, and it makes me vaguely concerned that something’s going to end up inadvertently tied to the WRONG container stack, just because of the order in which things were initialized.

Helge Heß:

It is the bug where SwiftData doesn’t refresh the object when the underlying object changes. I think I can hack-fix that ;-)

Deeje Cooley:

Apple needs to start internalizing the idea that APIs need actual internal app customers before they can be ready for third-party developers. Looking at you, SwiftData.

Fatbobman:

With WWDC 2024 approaching, this article will evaluate the overall performance of SwiftData since its initial release during the Xcode 15 period (i.e., its first major version), and provide a forecast of its future development.

[…]

Although SwiftData’s design is highly visionary, its launch was clearly rushed, and its first version not only lacks some important features, but several key issues have also severely impacted its performance and usability[…]

[…]

SwiftData’s current performance in converting predicates that include optional values (transforming predicates into SQL commands) is poor, especially when handling “to-many” relationships with optional predicates. This deficiency not only severely impacts SwiftData’s usability but also significantly restricts the functionalities that applications using SwiftData can offer.

[…]

Appendix: Some Key Features Missing, Major Issues, and Partial Temporary Solutions in the First Version of SwiftData

Previously: