John Gruber (Mastodon):
One might presume that the dedicated indicator lights are significantly more secure than the rendered-on-display indicators. I myself made this presumption in the initial version of my MacBook Neo review last week. This presumption is, I believe, wrong.
Later last week Apple published, and I linked to, a small update in their Platform Security Guide, which states:
MacBook Neo combines system software and dedicated silicon
elements within A18 Pro to provide additional security for the
camera feed. The architecture is designed to prevent any untrusted
software — even with root or kernel privileges in macOS — from
engaging the camera without also visibly lighting the on-screen
camera indicator light.
Guilherme Rambo:
[The] software-based camera indicator light in the MacBook Neo runs in the secure exclave part of the chip, so it is almost as secure as the hardware indicator light. What that means in practice is that even a kernel-level exploit would not be able to turn on the camera without the light appearing on screen. It runs in a privileged environment separate from the kernel and blits the light directly onto the screen hardware.
Previously:
Exclaves iOS iOS 26 Mac MacBook Neo macOS Tahoe 26 Privacy Secure Enclave
Random Augustine (2025, Hacker News, John Gruber):
The kernel shared in common between iOS, macOS, tvOS, visionOS and watchOS — named XNU — is based on a microkernel called Mach. However, the way XNU has been implemented places all system functions within the same privileged scope and it effectively operates as a monolithic kernel. The XNU kernel, like all monolithic kernels, suffers from unfortunately common vulnerability discoveries.
[…]
With the release of XNU source code supporting M4 and A18 based systems (such as the iPhone 16), the curtain was partly pulled back on exclaves. (Exclaves are not active on prior processors).
[…]
Exclaves refer to resources that are isolated from XNU, protected even if the kernel is compromised. These resources are pre-defined when the OS is built, are identified by name or id, have different types, are initialised at boot time, and are organized into unique domains. SPTM protects exclave memory from XNU with new exclave-specific page types.
[…]
To allow for execution of exclave Services while isolated from XNU, Apple has introduced a new kernel called the Secure Kernel (SK).
Thomas Claburn (Hacker News):
The term appears to have first surfaced in a libc file in Apple’s open source software collection in 2023, and subsequently within iOS 17, released in September of that year, as later noted by Howard Oakley on his Eclectic Light Co blog.
[…]
An enclave is defined as an area within a territorial boundary. So an exclave is an area outside of a boundary with ties to the main territory.
[…]
Essentially, Apple is trying to realize the security advantages of a microkernel without tossing the monolithic aspects of XNU.
Previously:
Apple A18 Apple M4 Exclaves iOS iOS 18 Mac Mach Kernel macOS 15 Sequoia Security
John Gruber:
But where I think Amodei’s remarks, quoted above, are facile is that it hasn’t played out as simply that lines of code that would have been written by human programmers are now generated by AI models. That’s part of it, for sure. But what’s revolutionary — a topic I’ve been posting about twice already today — is that AI code generation tools are being used to create services and apps and libraries that simply would not have been written at all before. It may well be that the total number of lines of code that will be written by people today isn’t much different from the number of lines of code that were written by people a year ago. But there might be 10× more code generated by AI than is written by people today.
Les Orchard (Hacker News):
Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical.
Now there's a fork in the road. You can let the machine write the code and focus on directing what gets built, or you can insist on hand-crafting it. And suddenly the reason you got into this in the first place becomes visible, because the two camps are making different choices at that fork.
I wrote about this split before in terms of my college math and CS classes: some of us loved proofs and theorems for their own sake, some of us only clicked with the material when we could apply it to something.
[…]
Here's what I notice about my grief: none of it is about missing the act of writing code. It's about the world around the code changing. The ecosystem, the economy, the culture. I think that's a different kind of loss than what Randall and Lawson are describing. Theirs is about the craft itself. Mine is about the context and the reasons why we're doing any of this.
John Gruber:
Orchard’s fine essay examines a philosophical divide within the ranks of talented, considerate craftsperson developers. The divide that I’m talking about has been present ever since the demand for programmers exploded, but AI code generation tooling is turning it into an expansive gulf. The best programmers are more clearly the best than ever before. The worst programmers have gone from laying a few turds a day to spewing veritable mountains of hot steaming stinky shit, while beaming with pride at their increased productivity.
There are additional groups. Some good programmers don’t use AI for coding. They’re against it for philosophical reasons, or it doesn’t apply well to their current project, or they haven’t taken the time or built the skills to really make it work for them. There are also hobbyists and people who know some programming, but are not really professional programmers, who are successfully using AI to help build tools for themselves.
CM Harrington:
Pssst… most software development was slop before AI.
Sure, your code was beautiful and artisanal and custom crafted to be beautiful, performant, and not at all created to be shipped in a fortnight between countless meetings with unclear goals and zero understanding of the bigger picture or user needs.
But those other folks…
Sam Altman:
I have so much gratitude to people who wrote extremely complex software character-by-character. It already feels difficult to remember how much effort it really took.
Jonathan Blow:
This is such a completely different reality from where I live, at this point it’s just difficult to say anything meaningful about it at all.
Previously:
Anthropic Artificial Intelligence Craft Programming Working
