Is this the reason OpenAI decided to steal Apple hardware secrets?
Of course not.
HN user
[ my public key: https://keybase.io/alwillis; my proof: https://keybase.io/alwillis/sigs/RYx1MNFlb1gNi9psXIHPpAttI8VT-rNbYRWt-Ex0gqo ]
Is this the reason OpenAI decided to steal Apple hardware secrets?
Of course not.
Pretty sure this isn’t the secret Jonny Ive project.
Every country and group has practiced slavery.
The colonies and, later, the United States didn’t just practice slavery; they industrialized it by transporting by force 12.5 million Africans to the Americas for nearly 250 years.
Even as fortunes were made, that didn’t stop the torture, rape, and brutality of these enslaved people.
Even after the Civil War, the descendants of the former enslaved people had to live under the Apartheid-like system of Jim Crow that lasted for another hundred years until the Civil Rights Act was enacted in 1964 and the Voting Rights Act in 1965.
I suspect they're subsidizing a lot less than people think.
Agreed.
Looks like all the reporting about Anthropic trying their earnest to turn a profit this quarter is true.
That's not how any of this works.
Anthropic is playing the long game; they're not going make a short-sighted decision just so they announce a profit for one quarter, which doesn’t mean much because it won’t be a sustainable profit since they're going to need to spend a ton of money on training and compute over the next few months.
That's why they did a G funding round for $14 billion in February and $65 billion in May.
I suspect one reason for switching Fable to API usage for the near future is they don't have enough compute for their enterprise customers and every hobbyist on their $20/month Pro plan, 80% of which don’t need Fable 5 anyway but that won't stop them from using it as much as they can.
We know an exception doesn’t necessarily prove the rule. macOS has always had superior text rendering support since the NeXT days.
SwiftUI is immature but getting better. There have been tons of AppKit apps with excellent text support. Don't know what this guys problem is.
A native macOS app done correctly is superior to a web app in virtually every way. Claude Desktop won't be a best-in-class app if it remains a web app. Simple as that.
If the purported benefits of agentic-coding systems are real, it should have been trivial for Anthropic to implement a native macOS application, and sell it as a benefit, no?
Absolutely. But there's the support, documentation and testing aspect and how they're setup.
To their credit, OpenAI acquired a team of experienced macOS developers when they bought Sky [1], the basis for the Mac version of Codex. Apple acquired Workflow from the same team years ago, which became Shortcuts, a core part of macOS's automation system.
Anthropic says 80% of their code is written by Claude; the remaining 20% requires some human expertise, especially with platform-specific features.
A native macOS version of Claude Desktop (and therefore Claude Cowork) would be a huge step forward for Anthropic. Hopefully it's a matter of when, not if.
I don’t understand how Gruber can think the ChatGPT app is that good. It’s also…fine,
It's not that ChatGPT is so good; it follows macOS design principles and functionality that have existed for decades. Claude Desktop sometimes does and sometimes doesn’t which can be a frustrating user experience.
It's the Mac version of OpenAI's Codex app where you see the night and day difference between the two.
I tried using RDFa and liked the property that it was theoretically less redundant, but switched to JSON-LD because it JSON-LD is just easier to get working.
For me, it depends on the project. For personal projects, I tend to use RDFa; otherwise, JSON-LD.
They don't conflict; they were designed to work together. You can have schema.org (in JSON-LD, RDFa, or micro data) on the same page as Dublin Core, etc.
For example, there's no explicit property in schema's Person type [1] for a nickname. But the FOAF standard does [2].
Just add FOAF to the JSON-LD context:
{
"@context": {
"@vocab": "https://schema.org/",
"foaf": "http://xmlns.com/foaf/0.1/",
"pronouns": "https://schema.org/pronouns"
}
You now use the FOAF nickname property: "@type": "Person",
"givenName": "Timothy",
"familyName": "Berners-Lee",
"foaf:nick": "TBL",
You can do the same thing with Dublin Core, DBPedia, etc.Check out “Bring an LLM provider to the Foundation Models framework” - https://developer.apple.com/videos/play/wwdc2026/339
Homebrew is the first thing I install on a new Mac.
Absolutely!
Just a FYI: Bundler now supports cooldown [1].
[1]: "Cool down before you install: give new gems a few days to be vetted" - https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-b...
Nothing new about it.
Besides starting at $599 (the Air has mostly been a $999 product; occasionally selling at $799 at Costco), coming in 4 bright colors with matching keyboards, using an A series chip for the first time in a Mac, containing 90% recycled aluminum (the most of any Apple product) and breaking all Mac laptop sales records, there's nothing new about it. /s
The MacBook Neo is a new idea. It’s also a device most Apple skeptics didn’t think was possible.
Personally, I would want that R&D spend and innovation to go to more sustainable materials, longer lasting devices, and easily repairable parts to extend the devices useful life.
Apple probably leads the industry in sustainability–the MacBook is 60% recycled material.
They’ve been working for years to be carbon neutral by 2030.
Details at https://www.apple.com/environment/
OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.
"Exploring Darwin and PureDarwin: The Open-Source Foundation of Apple's Operating Systems" - https://machaddr.substack.com/p/exploring-darwin-and-puredar...
Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard
Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch.
Whatever a firewall can do, PF can do it.
You can also get a nice GUI for PF [2].
In 2026, you can avoid the bad parts.
Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
By default, 16px = 1rem. You don't need to declare it; it just is.
Also by default, 16px = 100% if using percentage for font-size.
See "The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet" - https://adrianroselli.com/2024/03/the-ultimate-ideal-bestest...
Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.
If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.
Setting `font-size` in your CSS disables that second approach.
Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.
If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:
| CSS absolute-size values | xx-small | x-small | small | medium | large | x-large | xx-large | xxx-large |
| ------------------------ | -------- | ------- | ----- | ------ | ----- | ------- | -------- | --------- |
| scaling factor | 3/5 | 3/4 | 8/9 | 1 | 6/5 | 3/2 | 2/1 | 3/1 |
| HTML headings | h6 | | h5 | h4 | h3 | h2 | h1 | |
By default, medium is 16px which is 1rem.You can write `p { font-size: medium }`.
BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].
[1] https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop
From the docs:
CLAUDE_CODE_NEW_INIT
Set to 1 to make /init run an interactive setup flow. The flow asks which files to generate, including CLAUDE.md, skills, and hooks, before exploring the codebase and writing them. Without this variable, /init generates a CLAUDE.md automatically without prompting.
Jokes aside I find it hard to trust in the amount of things Anthropic throws out. It can’t be a well thought out and stable product this way.
I've never seen any company iterate on a product as quickly as Anthropic has with Claude. When you drill down into the details, it is well thought out and stable and well documented.
It seems the feedback loop is so fast, they address issues before they can fester into major problems. The entire company uses Claude; there's not better dogfooding than that.
It reminds me of how, back in the day, when continuous integration and continuous deployment were new; it seemed nuts to push code to production every day. And now, it's the norm.
But aren't they able to do incremental builds and separated x64/arm64?
During the PowerPC to Intel transition, they did stuff like that; perhaps at their current scale, there's reasons why they don't.
Supporting both architectures enables a macOS install to boot an Intel Mac or an Apple Silicon Mac, which is useful in a dual-architecture environment.
It's easy to check for dual architecture support; just use the file command:
$ file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (for architecture arm64e): Mach-O 64-bit executable arm64eYeah I’m honestly not sure why macOS updates seem to be so huge.
An update to macOS 26.5 contains all the necessary code to update a Mac from 26.0 to 26.5 for both x86_64 and arm64 architectures.
BBEdit has had support for Claude, OpenAI and Ollama (or any OpenAI-compatible LLM) in their AI Chat Sheets feature [1].
[1] https://www.barebones.com/products/bbedit/bbedit15.html#:~:t...
I've been using BBEdit since the System 7 days or thereabouts. Then I discovered Vim and I was hooked. And then came Neovim, which is still my daily driver.
BBEdit has been my never-fail backup editor, especially for Mac-specific tasks. It's been a little awkward because of my Vim muscle memory. Glad to see they're adding Vi/Vim keybindings, which I've wanted for a long time.
No, we should not praise software companies for hobbyist practices like selling $1 app on the App Store, which say, 30% goes to a digital distribution store, and then of your after distribution fees, about 20%+ percent goes to the federal and local government.
For hobbyists with revenue less than $1 million per year, the App Store commission is 15%.
You can use Language Server Protocol (LSP) in Claude Code; no more regexes [1].
I strongly suspect that the "coming soon" part of this means "after we integrate Google Gemini models into the system…"
I don’t think the Google's tech has anything to do with these features.
This would had to have been in the works long before the Google announcement. Also, these are enhancements of existing iOS and macOS features. They don’t require an LLM anyway; these features use Apple’s Machine Learning models.
For example, creating subtitles for videos? iOS 16 introduced Live Captions for FaceTime calls in 2022 [1].
[1] https://www.apple.com/newsroom/2022/05/apple-previews-innova...
The "coming later this year" language is disappointing to some people, but that's just Apple propriety. Allow me to explain.
"Coming later this year" means it's part of a publicly committed release — iOS 27, macOS 27, etc. — not vaporware.
The annual pre-WWDC accessibility announcement is a tradition, and with the conference less than a month away, expect more detail then. New a11y features have a good chance of appearing in the 10am PT keynote or the Platforms State of the Union, the developer-focused follow-up at 1pm PT.
That said, things are still fluid with three weeks to go — features can be added or pulled at any time. If something gets bumped from the main presentations, there will almost certainly be a dedicated video session covering it.
As for availability: some of these features will land in the iOS 27 and macOS 27 betas, which drop during WWDC for Apple Developer Program members. The public beta follows in July, and there's a free tier of the developer program if you want early access.
Don't expect everything at once, though. Some features won't arrive until the September release candidates — and even then, a few may ship labeled "beta" or "experimental," or hold for a future dot release.
In hindsight, ITCSS is so obvious. Makes you wonder why so many people think CSS is difficult.