ACS_Solver

I think the whole framing of climate issues as "saving the planet" is misguided. Yes, the planet will remain livable pretty much no matter what. The threat of climate change isn't the literal destruction of the planet, or even the literal extinction of humanity. Rather it's such severe changes to the planet's biosphere that human civilization would be threatened.

Potential climate catastrophe scenarios where rapidly rising sea levels submerge many inhabited areas and various knock-on effects disrupt the food chain, even in those scenarios the planet is fine on geological timescales. What's not fine is human civilization, on human timescales. And I think this is what gets inadvertently hidden behind planet-saving rhetoric. If the worst case scenarios are "only" about billions of people dying due to resource scarcity and conflicts over said resources, this is something to be avoided.

I see a parallel with global nuclear war. Such a war would probably not end the species, there would be groups of survivors here and there. But human civilization as we know it would be over, with the global population being back to what it was in the hunter-gatherer era.

Yes, sure. But I am talking about Europeans, not Americans, who know 911. I see kids here who are familiar with 911 just through American media, which is really the only source here for anyone to know the number.

More accurately, 112 is the EU emergency number (and the GSM standard) but actual organization of emergency services is entirely national so who deals with your call and how will be local. The article also points out that handling of 911 is local in the US, even if apparently most 911 dispatchers are somehow subordinate to the police.

Also, like 112 forwards to 911 in the US, most cell networks in the EU will forward 911 to 112. American cultural dominance has made it so everyone knows 911 and even Europeans apparently end up dialing it.

I am not surprised - the general pattern with Torvalds seems to be that he's maximally pragmatic. His problems with say Nvidia drivers aren't the fact that they're proprietary, it's that they are difficult to interface with the kernel. I have a strong impression that what matters to Linus is software that works well, so he cares a lot about the quality of the kernel and ideally wants other software to be similarly reliable.

If he judges that Claude does the best job, it'd be very much like him to use Claude. It would be unlike him to use an open program if he considers it inferior.

Most tablets were air dried, which would take a day or two. But some tablets were fired - dried in a kiln. I don't know about Hittites but at least in Mesopotamia, air drying was by far the most common method and only some important ones were fired. So methods were certainly available to dry a tablet quickly if necessary but I doubt if air drying delays made much of a difference. Messages and goods were limited to the speed of horse after all.

Yes, good name and I also feel that was a major inflection point. Up until then I found all AI models to be terrible at programming, with the difference between GPT o3, Sonnet 4 and every other model since GPT-3 being just the exact flavor of terrible they were.

November 2025, with Opus 4.5, was the first time I was impressed by an LLM doing something non-trivial with a reasonably good level of quality.

I love displays from space vehicles and nuclear plants for the same reason. Data and controls organized in a dense but presumably highly usable manner. And it covers the more specific view of an expert in a particular subsystem, as well as the higher level view of those responsible for the whole system.

> Many of us, deep down, are driven more by the joy of making things, solving problems, and seeing people use what we built than by the act of coding itself. After all, many of us decided we wanted to be developers before learning to code, just to create video games or websites. The desire came before the code.

This is a big disconnect that I think has been at the root of many different reactions to LLMs lately. Here on HN I see a lot of "I hate what LLMs did to programming" and equally a lot of "LLMs are awesome, I've never had a better time". I think the disconnect is between people who build software for the end result (having users, the joy of completing a thing, etc) versus building it for the process itself (architecting, coding, debugging).

I'm mainly the kind who enjoys the process. I think of an awesome startup job I had that solved real problems for real customers including some really big firms, but I can't honestly say I ever cared about those problems or the customers. I loved the job because it was technically challenging with a lot of freedom, and the customers were great because they were a source of new interesting details to solve, as well as confirmations that the previous solutions worked.

As such LLMs make me sad because they effectively replace a lot of what I like doing. Doing a refactor to support a new feature, digging through the code to try and understand a bug. One of my strengths as a developer, I think, is that I am fast at familiarizing myself with unfamiliar codebases. That's also a somewhat redundant skill as Claude can answer "how does feature X work in this code" in a small fraction of the time it'd take me.

A few years ago (before the LLM craze) I moved to game dev as my main job, which makes a lot of this easier because I actually care about the end product and the customers (players), so that's a whole new layer of satisfaction in addition to the usual technical one.

Which isn't to say that it's all bad. I've used Claude to get a few things done where I mainly care about the final result and not the process. There was one such project I wanted to get done, I'd had the idea and the data for five or six years, but I found that the implementation would be time consuming, often manual work and much of it involving the kind of tech I don't really enjoy. So I never worked on that but last month, I did the whole thing in a few days with Claude and got exactly the result I wanted.

This can't be the first time you're seeing such use of Я? It's very commonly used in Western typography / graphic design as a symbol to invoke associations with Russia. It's not being used as a Cyrillic letter, it's being used a "think of Russia" and people unfamiliar with Cyrillic will mentally associate it with R so TETЯIS is easily read as "tetris". Even if yes, people familiar with the alphabet find it harder because the first reaction to Я is to in fact read it correctly.

Same with Σ being used as a "think of Greece" symbol that people from Latin-script languages are expected to process as E, leading to "brilliant" designs in GRΣΣK. Or how the Chinese character 山 would remind a Russian speaker of Ш so ПО山ЛИ would be easy to read.

I'm in game dev but I also have very poor abilities for mentally operating on visual or geometrical data. I'm normally far away from the graphics parts but sometimes I take a look and shaders are by far the least intuitive type of code to me. I've learned enough about what shaders do to sort of parse the simple ones, but anything with shaders definitely feels like working against my brain's natural tendencies.

However, protective equipment is taken seriously and then shoes stay on. Here in Sweden, of course ordinarily all shoes are taken off (for 8-9 months of every year they're wet and dirty) but if workers come in to do some work, they keep their shoes on because they're protective equipment. If you're having them come during a particularly dirty time of the year, you may want to cover your floor with newspapers or give them shoe covers.

> Even worse, recently, after getting another opus in a tiny bugfix session, I prompted directly, "drop the comments from the current code changes" — Claude instead just slightly trimmed them. I couldn't believe my eyes.

For me, Claude knows how I want the comments due to all the memories and CLAUDE.md, so funnily it's now enough with even a brief groan from me like "Come on, the comments" and then Claude goes through its recent additions and fixes comments quite well per my long-term instructions. But only ever during an extra pass that I initiate, never during the initial writing of the code.

I also suspect comments are very much tied to how Claude reasons because not only are they bad comments, I can't get rid of them. Commenting is the one area in which I've been unable to get Claude to respect any rules. It can follow code conventions I prefer, it can do other things, but it can't keep the comment volume down.

My CLAUDE.md has rules about not including any redundant comments in the code that are obvious from the code itself. I reiterate that occasionally while working. It's absolutely disregarded and any Claude-written code is full of comments. Some of them are simply redundant, like "Collect Foos and pass them to the requested sink" on a function that's void CollectFoos(IFooSink sink). But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.

I haven't found any way to stop Claude from doing these, so I have to tell Claude afterwards to clean the comments up. Which it does, making a note in memory to comment less, and it still does the exact same thing next time.

I wouldn't generalize Europe like that, our differences in the normal schedule are massive from north to south.

Here in Sweden, it's a morning culture. Blue collar workers often start work at 7, daycare is open from 6 in the morning for parents with early jobs, dinner is at 18 or even 17 for people. At 22, most places are closed including supermarkets and restaurant kitchens. Lunch for the vast majority of working people is at noon.

That is totally different to a country like Spain, where you see families - with kids! - start dinner at 21 or later. In Sweden people would say it's strange not to have your kids in bed by then. Lunch is at 14, cities are full of life until midnight every day.

A large part of that is probably due to daylight hours. A big chunk of Sweden is dark by 16 for the winter half of the year. During November-January there's minimal light and it's gone by 15.

> Even if you deeply into tinkering, 1 can be an insanely exciting and rewarding step: for example "how could an abstraction look like in which 2-4 become trivial special cases for many classes of programming problems?".

Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".

As the tinkering type, I also find 1 very rewarding but using the latter definition. Exploring a sizable code base and finding the part that, if simplified, cascades to a lot more simplification, that's very exciting. Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.