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.
> 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].
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
> 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.
> 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.
> 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.
> 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:
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].