Archive for August 12, 2025

Tuesday, August 12, 2025

Reddit Will Block the Internet Archive

Jay Peters:

Reddit says that it has caught AI companies scraping its data from the Internet Archive’s Wayback Machine, so it’s going to start blocking the Internet Archive from indexing the vast majority of Reddit. The Wayback Machine will no longer be able to crawl post detail pages, comments, or profiles; instead, it will only be able to index the Reddit.com homepage, which effectively means Internet Archive will only be able to archive insights into which news headlines and posts were most popular on a given day.

Nick Heer:

Unfortunately for many publishers, the Archive seems to be perfectly happy with scrapers and is unbothered if its collection is used to train artificial intelligence.

Why doesn’t the Internet Archive repeat the crawling policy of the original site? Otherwise, it essentially becomes a Napster for data laundering.

Previously:

GitHub CEO Resigns, Not Replaced

Thomas Dohmke (tweet):

From building mobile developer tools, to running the acquisition of GitHub alongside Nat Friedman, to becoming GitHub’s CEO and guiding us into the age of Copilot and AI, it has been the ride of a lifetime.

Still, after all this time, my startup roots have begun tugging on me and I’ve decided to leave GitHub to become a founder again. GitHub and its leadership team will continue its mission as part of Microsoft’s CoreAI organization, with more details shared soon.

Tom Warren (Hacker News):

GitHub has operated as a separate company ever since Microsoft acquired it in 2018 for $7.5 billion, but Dohmke’s departure is part of a big shakeup to the way GitHub operates. Microsoft isn’t replacing Dohmke’s CEO position, and the rest of GitHub’s leadership team will now report more directly to Microsoft’s CoreAI team.

[…]

GitHub no longer has a single leader, or CEO, and responsibility for GitHub will align more closely to the CoreAI leadership team. GitHub’s reporting structure originally changed in 2021 when former CEO Nat Friedman stepped down, and Dohmke reported up to Julia Liuson, head of Microsoft’s developer division. Liuson then started reporting to Parikh earlier this year with the formation of the CoreAI team.

Previously:

JSONSerialization Can Throw NSExceptions

Peter Steinberger (tweet):

lol of the day: Apple’s JSONSerialization can throw NSExceptions. These cannot be captured in Swift. Gotta go back to ObjC and write a wrapper.

The documentation suggests that to avoid this you can first call isValidJSONObject(). Of course, you have to remember to do this, and it adds overhead to the common case where the object graph is valid. I don’t understand why Apple can’t just return an NSError, as NSKeyedArchiver was modified to do.

Working around this sort of thing using a general-purpose Objective-C wrapper is in general not safe because the exception is being thrown through a Swift stack frame (from the passed-in block) before being caught in Objective-C. However, it’s fine to create a bespoke Objective-C wrapper to convert exceptions into errors for a particular API. I do this for NSManagedObjectContext.save().

Previously:

Update (2025-08-13): Timothy Wood:

My strongly held opinion after ~30y doing this shit is the right answer is to just crash (and make sure your crash reporting/aggregation/investigation pipeline is in order).

[…]

But once an exception is thrown through code that doesn’t expect it, all bets are off and anything could potentially be corrupted/invariants destroyed/etc. In this case, saving the file was what theoretically caused the exception and so your handler has to deal with possible reentrancy. But if the user manages to save their document, and mail you the info, they might feel like everything is fine now -- they clicked the buttons and did the thing -- and then continue on editing other documents in an app that’s bleeding internally.

SwiftData Runtime

Richard Witherspoon:

I’m working with SwiftData and trying to replicate behavior similar to what I used to do with CoreData, where I had an extension on NSManagedObjectContext that allowed me to fetch all stored objects, regardless of entity type.

[…]

I’m now using SwiftData with @Model types and the ModelContext, and I want to dynamically fetch all objects from the store at runtime, without manually specifying each type. I understand that SwiftData is designed to be more type-safe and less dynamic than CoreData, but is there any way to accomplish this without traversing through the raw SQLite file manually?

This sort of metaobject stuff is really easy to do with Core Data, using public APIs available from the very first version. Currently, with SwiftData you need a fragile Mirror hack to get a PersistentModel from a Schema.Entity.

Previously: