Another question: how does this approach compare to trying to repair the pathogenic variants in the cancer? I asked here about that approach recently and the response was mainly about delivery difficulties: https://news.ycombinator.com/item?id=48285386

The rare exception: https://en.wikipedia.org/wiki/Clonally_transmissible_cancer

I've heard about drug resistance in bacteria leading to slower growth / reduced virulence. Maybe the same would occur with cancers. A drug that could effectively switch an aggressive cancer into a slow-growing one wouldn't be the worst thing.

First link is announcing the initiative was submitted, second is a private meeting where the initiative was presented to the comission by the organizers.

Then there was a public meeting on 16 April 2026 and a public meeting on 20 May 2026.

Is there a specific part of one of those meetings that indicates they want to go a different direction than the California bill?

From the last link:

> If designed responsibly, most games that connect to the internet can operate indefinitely without publisher support. This has been a customer expectation for over 50 years. We are open to any solution that solves the problem. We are flexible on specifics and implementation by publishers. We understand that not all game features may be operable in a discontinued game. We are not seeking ongoing support from publishers after a game has been discontinued

This sounds like the California bill would address these issues.

edit: Particularly, I'm wondering if there is any serious push for release of binaries / source code prior to the end-of-life of a game, which seems to be of particular concern.

Fans have reverse-engineered and stood up servers for tons of games with no access to the server binaries. The idea that they wouldn't figure it out when given much better resources (server binaries or source code) is crazy.

Where can we find information about the direction the EU is going on this? AFAICT there has just been one meeting on the topic?

How about for lymphomas?

There is still the part of the ceremony that actually mattered: having a single entrypoint instead of the option to litter side effects throughout the file and having those side effects execute automatically on import.

> It sucks, but what's the alternative?

3.0 was a big missed opportunity to kill a lot of the deprecated cruft.

Block agents from misbehaving at the OS level instead of asking them to behave.

This one is quite tinfoil-hat inspiring, as the research was moved to defense-focused Draper Labs and then immediately disappeared.

Seeing him type really reinforced this idea.

1) Higher level code is easier for LLMs to review and iterate upon. The more the intent is clear from the code, the easier it is for humans and LLMs to work with.

2) LLMs get stuck or fail to solve a problem sometimes. It is preferable to have artifacts that humans can grok without the massive extra effort of parsing out assembly code.

3) Assembly code varies massively across targets. We want provable, deterministic transformation from the intent (specified in a higher level language) to the target assembly language. LLMs can't reliably output many artifacts for different platforms that behave the same.

4) Hopefully, we are still reviewing the code output by LLMs to some extent.

1) wanting functionality that isn't provided and working around that

and

2) restoring such functionality in the face of countermeasures

The absence of functionality isn't a clear signal of intent, while countermeasures against said functionality is.

And then there is the distinction between the intent of the software publisher and the intent of the user. There is a big ethical difference between "Mozilla doesn't want advertisers tracking their users" and "those users don't want to be tracked". If these guys want to draw the line at "if there is a signal from the user that they want privacy, we won't track them", I think that's reasonable.