gregates

"The ICE stuff" means what ICE is actually doing, not some abstract, lawful policy that you could imagine instead. This is precisely the point. Many people who voted for Trump did not understand what they were going to get.

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

The ICE stuff is extremely unpopular. Most of the people who voted for it did not understand they were doing so. If "the US" is the people, then no, they mostly do not want this. If "the US" is Trump, then yes, it is.

This is also the most important political question in the US right now. Are the people still sovereign?

The Silmarillion is riveting and concise! I will grant that it's not a novel.

I looked at applying there way back in 2020 and bounced off the application because it seemed like more work than I had time for.

oh you mean the thing where I randomly have to press 0 to get back to the normal interface?

And yet somehow it never predicts, "Wait, back up, three turns ago I said we wanted to do X. You did Y which is the opposite of X," which I write pretty frequently!

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."

nitpick: I was fully engaged with this article until I hit

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

Alternatively, things that are not insightful can feel insightful to some people, because they triggered some different, tangentially related thoughts than what was being communicated — i.e., the reader substituted their own insight for the author's.

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.

It really is important to understand the failure modes that the durability model accounts for and what it doesn't. It only accounts for "normal" failures, like an HDD reaching end of life.

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!

Aristotle thought some fish were spontaneously generated and others not (also all eels and Testacea).

"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.

> On the topic of Michael's comment, I think it's easy for programmers to not notice ads. Almost all programmers I know use an ad blocker and, in real life, their eyes seem to just skim over ads and not notice them.

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?

The title of the article is misleading -- they're pretty clearly talking about philosophy PhDs here.

The implicit assumption is that these AI-company jobs were recently created and indicate the start of a trend.

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.

What you're missing is that this is approximately at least a half-dozen more jobs than open tenure-track positions at research universities.

I came up an academic philosopher, before I switched careers. When you're surrounded by academic philosophers, you become very used to argument as a default form of interaction. People expect that they'll be asked to give reasons for their assertions, and that those reasons will be scrutinized and challenged.

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.

Given how often it's been mentioned here, it's likely that this is an urban legend that people are pretending to have first-hand knowledge of for karma. In a trade that's supposed to be led by people trained in sciences, no less!

(A more charitable interpretation would be that aforementioned CTO was making a joke that didn't land.)

Funny, I'm just doing my normal coding workflow with Claude Code, and after every change that compiles it keeps suggesting that we're at a good stopping point, and should pick up again tomorrow.

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.

Hate to be the one to drag AI into every conversation, but I recently switched to arch linux and it's been delightful -- largely because of Claude. I have leaned on Claude heavily to diagnose and resolve issues that I probably could have theoretically solved on my own, but which also probably would have made me switch back if I didn't have help to resolve them quickly.

(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.)

Indeed you can! I don't use IntelliJ at work for [reasons], and LSP doesn't support a change signature action with defaults for new params (afaik). But it really seems like something any decent coding agent ought be able to one shot for precisely this reason, right?

In the case I described no code changes have been made yet. It's still just planning what to do.

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.

Indeed! You would think it would have some kind of sense that a commit that obviously won't compile is bad!

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.

The version of this I encounter literally every day is:

I ask my coding agent to do some tedious, extremely well-specified refactor, such as (to give a concrete real life example) changing a commonly used fn to take a locale parameter, because it will soon need to be locale-aware. I am very clear — we are not actually changing any behavior, just the fn signature. In fact, at all call sites, I want it to specify a default locale, because we haven't actually localized anything yet!

Said agent, I know, will spend many minutes (and tokens) finding all the call sites, and then I will still have to either confirm each update or yolo and trust the compiler and tests and the agents ability to deal with their failures. I am ok with this, because while I could do this just fine with vim and my lsp, the LLM agent can do it in about the same amount of time, maybe even a little less, and it's a very straightforward change that's tedious for me, and I'd rather think about or do anything else and just check in occasionally to approve a change.

But my f'ing agent is all like, "I found 67 call sites. This is a pretty substantial change. Maybe we should just commit the signature change with a TODO to update all the call sites, what do you think?"

And in that moment I guess I know why some people say having an LLM is like having a junior engineer who never learns anything.

I had a fun experience with my ISP where their chat bot couldn't help me (of course it couldn't, I don't call for "did you try turning it off and on again" problems), so it escalated me to a human agent. Said human agent was very obviously copy-pasting LLM output. I could tell because (1) the responses were nearly identical to what Claude already told me when I asked it before calling and (2) every once in a while I would get an uncharacteristically brief reply, without capitalization or punctuation, in Indian English.

I haven't a had a good experience since AT&T bought my previous ISP and forced me to switch to a different subsidiary.

I was a MS-DOS 2.0 user as a child. I have always preferred windows to OSX. I used WSL for years at companies where every other engineer had a MacBook.

Last weekend I finally started dual-booting Arch Linux as a trial. Yesterday I deleted my windows partition.

Too late, Microsoft.

VisiCalc didn't do this, though. It just recalculated once, and if there were errors you had to notice them and manually trigger another recalc.

> Since the formulas did depend on each other the order of (re)calculation made a difference. The first idea was to follow the dependency chains but this would have involved keeping pointers and that would take up memory. We realized that normal spreadsheets were simple and could be calculated in either row or column order and errors would usually become obvious right away. Later spreadsheets touted "natural order" as a major feature but for the Apple ][ I think we made the right tradeoff.

It would seem that the creators of VisiCalc regarded this is a choice that made sense in the context of the limitations of the Apple ][, but agree that a dependency graph would have been better.

https://www.landley.net/history/mirror/apple2/implementingvi...

Edit: It's also interesting that the tradeoff here is put in terms of correctness, not performance as in the posted article. And that makes sense: Consider a spreadsheet with =B2 in A1 and =B1 in B2. Now change the value of B1. If you recalc the sheet in row-column OR column-row order, B2 will update to match B1, but A1 will now be incorrect! You need to evaluate twice to fully resolve the dependency graph.

Indeed — the only reason I personally still use steam is that a few of the games I want to play are not available in any other (legal) way.

Alright you badgered me into reading the original and the linked post does not misinterpret it.

> Previously, we could @cursor and ask it to modify the code and content, but now we introduced a new CMS abstraction in between. Everything became a bit more clunky. We went back to clicking through UI menus versus asking agents to do things for us.

> With AI and coding agents, the cost of an abstraction has never been higher. I asked them: do we really need a CMS? Will people care if they have to use a chatbot to modify content versus a GUI?

> For many teams, the cost of the CMS abstraction is worth it. They need to have a portal where writers or marketers can log in, click a few buttons, and change the content.

> More importantly, the migration has already been worth it. The first day after, I merged a fix to the website from a cloud agent on my phone.

> The cost of abstractions with AI is very high.

The whole argument is about how it's easier to use agents to modify the website without a CMS in the way.

This is an AI company saying "if you buy our product you don't need a CMS" and a CMS company saying "nuh-uh, you still need a CMS".

The most interesting thing here is that the CMS company feels the need to respond to the AI company's argument publicly.

> Lee's argument for moving to code is that agents can work with code.

So do you think this is a misrepresentation of Lee's argument? Again, I couldn't be bothered to read the original, so I'm relying on this interpretation of the original.