gregates
This is also what happened to all those male Ashleys in the 70s. People picked up on the name's trendiness, but didn't initially realize it was vastly more popular for girls and would soon be seen as feminine.
I think a lot of these cases would be hard to answer definitively just because we don't really have accurate data. And the fact that lots of people will repeat the claim "Ashley used to be a boys name" can be equally well explained by the fact that parents had to say something when their sons asked why they gave them a girl name, and they didn't have the data either.
To take Ashley as an example. This name suddenly started ramping up in popularity in the 60s. In 1970, there were 927 girls named Ashley in the U.S. It peaked at 54,856 in 1987.
It became notably more popular for boys at roughly the same time! The peak of M Ashley was in 1980, at 746. (Note: it's also very likely that these numbers are wrong. The SSA data also has 56 male Marys in 1980, which is likely the result of coding error.)
Meanwhile, in 1945, solidly in the time period when the article would like you believe that Ashley was solidly a boys name, there were 57 M Ashleys and 10 F. 1950 was 55 M/15 F. Prior to 1960, a "good" year for Ashley was around 100 total babies, with some split of both M and F.
To me, a more honest interpretation of this data is that Ashley was a somewhat unisex, but mostly just very uncommon, name that suddenly became trendy in the 1960s, especially for girls but also for boys.
It did fall in popularity much faster for boys than girls, perhaps as it became to be perceived as feminine due to its popularity for girls. But note that even today, Ashley is still used as a boys name! There were 69 M Ashleys in 2009 and 27 M Ashleys in 2025 (by which point the prevalence of coding error is much lower -- M Mary has fallen out of the data set entirely).
The 2025 F:M ratio of 1829:27 is pretty high, so it's fair to say that Ashley would now read as feminine to many Americans (but note, still less so than Mary). It's much less clear to me that you can conclude from the 1945 M:F ratio of 55:10 that it was once a boys name.
Actual support for Trump's immigration policy and ICE is much lower than you suggest.
https://www.foxnews.com/politics/fox-news-poll-majority-says...
This is also the most important political question in the US right now. Are the people still sovereign?
Or "I have emphasized repeatedly that you're not to touch vcs and only work in the designated worktree, which you've written down in your memory at least 37 times."
> And a bonus point: you skim. Did you notice number 5?
Then I bounced. The best readers skim aggressively. Most text is not worth reading. You skim to identify what is.
But moreover, reading != proofreading. I read every one of the bullets! I did not pay attention to the numbering scheme, because it conveys no meaning. It's a structural affordance for referring to the text, not part of its content.
Or because the author has enough authority that they are granted a presumption of insightfulness by default, even (or perhaps especially) when the concrete insight that's allegedly being communicated remains unclear.
For example, you mention Backblaze. Backblaze has public posts about their durability model. They claim to use 17:20 Reed-Solomon erasure encoding. That means there are 20 shards of a blob, and you can lose 3 of them and still reconstruct the blob.
Think about that for a second. If they store 4 shards in a datacenter, that means that a loss of that one datacenter is sufficient to lose the blob, forever. That entails that blobs are sharded across a minimum of 7 data centers, or the loss of one data center might mean permanent data loss. Which one do you think is true? (In fact it's pretty clear from Backblaze's public posts that they don't shard across data centers at all, only across racks within a data center.)
Now, AWS's availability guarantee — not their durability guarantee — entails that they use a less cost-effective erasure coding ratio. S3 is designed so that your blob is available even if a whole AZ goes down, and it's well known that most AWS regions have only 3 AZs. Therefore, if you tolerate the same number of shards lost to HDD failure as Backblaze in your durability model (3), then you might need 17:30 erasure coding to get the same durability and the required availability. That means S3 is storing way more physical bytes than Backblaze — 1.76x the logical size of the blob, instead of Backblaze's 1.18x. That's more expensive, but it also gives you better availability.
Which is also why One Zone S3 is cheaper — if you don't care about the availability guarantee, S3 can do what Backblaze does and save 33% on physical bytes, and they pass on 40–50% of those savings to the customer (this is fairer than it sounds — there's more overhead than physical storage bytes).
But here's the thing. AWS has more redundancy built in than Backblaze because they make availability guarantees in addition to durability guarantees. BUT the durability model is the same, which is why Backblaze can claim equivalent durability to S3. S3 in fact has better durability — they can survive the permanent loss of an AZ without necessarily losing blobs stored there (with the exception of One Zone blobs), and Backblaze cannot. But that's not actually a factor of the durability model, which is just taking into account normal events like HDD failure. Instead, S3 has durability that's more resilient to AZ loss because of their availability model. It's a side effect that isn't actually part of the durability promise!
"This occurs in ponds, especially one near Knidos, which, so it is said, on one occasion dried up at the time of the Dogstar and all the mud was taken out; water began to collect in it as the first <rains> came, and at that point tiny fishes appeared, as soon as the water began. This fish was a kind of grey mullet which is not produced as the result of copulation, and its size was about that of a small sprat: none of them had either egg or milt. (...) This evidence shows that certain fishes are produced spontaneously, and do not come out of eggs or from copulation" (HA VI.15 569a13-19, 25-26).
This is something of a problem for Aristotle, since the formal cause appears to be absent in spontaneous generation. He likely would have been happier to discover that spontaneous generation does not, in fact, occur for animals. But he felt that the evidence forced him to concede that it does.
How do you write this article and not notice that this should be the topmost example of people adapting to buggy software that doesn't at all work for its users without workaround cognitive hacks?
Chalmers is stating that there's more demand for philosophers with the right sort of training to work at AI companies (whatever that is) than there are philosophers with that training. (I don't really believe this, but that's what he says.)
He's making this claim for two reasons: (1) to respond to the argument (not directly stated in the article, but quite commonly understood to be sound in the profession field) that it's unwise to get a PhD in philosophy because there are not enough jobs and (2) to suggest that if you do want to get a PhD in philosophy and use it professionally, you'd be wise to study with Chalmers at NYU in order to get placed into these tech-industry jobs.
And it's great! You can learn a ton from having these arguments with smart, engaged interlocutors. It's not that ego doesn't come into it at all. Often, the "loser" of the argument -- and there isn't always one! -- won't admit they're wrong, and at some point will just bow out and live to fight another day. But the point is that everyone agrees they need reasons for their beliefs, and rebuttals to strong objections, and if they lack those they need to go find them. So the arguments serve to help you find those gaps. People argue because they want to be right, but being right is hard. So you work at it. You aren't just trying to assert dominance, you're trying to prove -- to yourself, first and foremost -- that you have the right beliefs! And if you can't, you might even change your mind.
Leaving that world was eye-opening, because I still expected people to feel a powerful need to justify their beliefs. But most people don't, and they take the mere act of asking for justification to be a personal attack. This cost me relationships with people until I really learned the lesson.
(A more charitable interpretation would be that aforementioned CTO was making a joke that didn't land.)
It's done this before, but usually doesn't. I bet they're giving it some kind of throttling signal due to high load from today's announcement.
(Yes, I know arch linux is not what you want if you're a "I just want something that works" person switching from windows. That's not me, I'm more of a "I want all the control and responsibility guy". I just don't have four hours to spend figuring out how to get hardware video acceleration working in vlc by trial and error the first time I try to play a video. Twenty minutes though? OK. I'll even learn something in the process.)
It's true that I could accept the plan and hope that it will realize that it can't commit a change that doesn't compile on its own, later. I might even have some reason to think that's true, such as your stop hook, or a "memory" it wrote down before after I told it to never ever commit a change that doesn't compile, in all caps. But that doesn't change the badness of the plan.
Which is especially notable because I already told it the correct plan! It just tried to change the plan out of "laziness", I guess? Or maybe if you're enough of an LLM booster you can just say I didn't use exactly the right natural language specification of my original plan.
You would think.
It would be one thing if it was like, ok, we'll temporarily commit the signature change, do some related thing, then come back and fix all the call sites, and squash before merging. But that is not the proposal. The plan it proposes is literally to make what it has identified as the minimal change, which obviously breaks the build, and call it a day, presuming that either I or a future session will do the obvious next step it is trying to beg off.