Depending on how the LNPs are designed, would resistance also potentially cripple the cancer cells? Like, it stops surfacing some cholesterol receptor because the drug is being delivered by LNPs that target that receptor, and now the cell is starved for cholesterol?
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.
>Depending on how the LNPs are designed, would resistance also potentially cripple the cancer cells?
Yes, if the LNP could be engineered to target an essential surface receptor, which is still a very tough problem. It would also not solve the issue of the payload successfully entering the cell but being subsequently degraded.
>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.
This is essentially how treatment for chronic lymphocytic leukemia happens (hence why it's called "chronic"). People with CLL can stay on BTK inhibitors for decades, often until they die of other natural causes.
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
Even with 100% delivery efficacy, editing efficacy is nowhere near 100%. CRISPR/Cas editors will reliably detect the target sequence but will not reliably edit it in order to repair the mutant allele, whereas CRISPR/Cas12a2 will activate and destroy chromatin ~100% of the time when it detects the target.
As is often the case, it's a lot easier to indiscriminately destroy than precisely (re)build.
>would resistance also potentially cripple the cancer cells?<
this is the concept of genetic baggage, and metabolic budget.
there is only so much energy to a cell, and scant amounts to "waste" on preservation of something that is not used. in the long term, carrying unused properties are disadvantageous, and reduce reproductive output [replication]
the result is "unfettered" oncocytes outgrow those with baggage, and occlude access to resource. if there is no challange that reduces population of nonresistant cells, the resistance will be minimized and extinct in the face of large disparity of success.
If a game is popular enough for anyone to care, some turbonerd will get the server running on a massive cloud instance, and then people will be able to play the game.
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.
>The idea that they wouldn't figure it out when given much better resources (server binaries or source code) is crazy.
i wasnt implying they couldnt figure it out.
i was implying that you would have to be an incredibly rich turbonerd to stand up a massive cloud instance for some of these games. which sort of defeats the entire goal of the regulation.
Or maybe 100 years from now, your toaster will be powerful enough to run the game.
To me this is about both preserving the access to what consumers purchased, but also future preservation of art.
Copyright is not a natural right. It is a monopoly granted by the government to creators, specifically with the goal of the progress of art and science.
Games that completely die because their servers are shut off, in my opinion should just lose copyright outright. Why should the people via the government provide you with a monopoly on publishing something that you have stopped publishing?
Seems like that's... one more substantive meeting?
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.
theres a lot of pre-meetings, some major meetings (the ones you mentioned) and talks about getting legislation into other acts.
The fact here is pretty simple: they have not indicated any support for the californian style legislation and they aren’t done yet either. The californian model is also very direct and instructive and EU laws tend to be broad frameworks, so they’ll definitely be different in some way, but unsure if they’ll encompass each other.
I can’t say what way they will definitely go, but it seems naïve to presume the californian stance given how disparate the solutions are from with in the SKG movement itself.
I’m watching it closely, obviously, but nobody knows where it will go. But this is like a 500-sided dice, the odds are low that a solution cleanly overlaps.
Imagine if every tweet had to go through a one-at-a-time queue before being persisted. There's about 6000 tweets per second, so you would have to be able to save them at <0.17ms per tweet or else you would become backlogged. If you are getting backlogged, you have to buffer those incoming tweets somewhere until they can be writted, and eventually that buffer gets full and you start losing tweets.
Maybe that too is a native question, but there's a large scale between single user and 6000 tweets per second - most of our apps will never reach anything approaching even one save a second. So where to draw the line? I do far have gone the sqlite route for my hobby apps as it's so easy to handle and doesn't require setting up two docker containers for a single app. Am I drawing myself in a corner in case my apps ever do become relevant?
Excellent question, and I spent so many years asking myself it, this over and over. You asking it made me realize I just...don't anymore. So allow me to blather a bit / free associate because I won't be sure why myself until I've written it out.
TL;DR: whatever works for you is the right decision. (which isn't helpful, I heard this so many times and as the recipient, I thought "That's nice. Now how do I choose what works for me?")
I finally had to use Postgres a couple years ago after a career of only SQLite - startup founder & iOS app developer using SQLite, turned Googler on Android, turned doing-my-own-thing.
In retrospect, I have made only one bad decision:
I went way out of my way to make SQLite work at my 2009-iOS-startup. It was a restaurant point of sale system, and to allow a networked system, one of the iOS devices would act as a server. This was a really cool trick, even an advantage in marketing that was appreciated by users. It meant the restaurant could continue to operate if the internet went down. But it eventually became clear owners loved having internet-based access too, ex. to do reporting/financial analysis over the data. And I kept contorting, instead of moving past my fear of getting into things I didn’t know, I instead did some like rudimentary thing over port forwarding. The bad decision here was riding one horse for so long and letting it affect the product, having a real server database would have allowed for a lot more features, think, first party gift cards, and a 100 others.
After leaving Google I needed server-side storage and fought and fought to avoid it. Then it turned out Postgres is easy and, just like SQLite, 99.999% of the time I don’t even know I’m using it.
In retrospect, there’s ~0 switching cost to these, particularly in age of LLMs. If you do need something more one day, it’ll be easy to do, and if you have to do it in a rush because you’re successful, you’re in Good Problem territory.
Hope that helped, after writing it out, dunno how convincing it is. Feel free to follow up, I appreciate the curiosity/framing because I had the same thought for so long.
If we imagine 1 tweet = 1 transaction, that's only 6k tps. 6k tps is completely achievable, dare I say even pedestrian for an optimized database. And most systems are operating far below the scale of Twitter/X.
Round trip time is actually much faster than Postgres, since there’s no need to touch the network. You can get massive single threaded throughput. In order to achieve comparable throughput in Postgres you need a large amount of concurrent connections, since each conn spends most of its time passing messages, deserializing etc (with a much larger total amount of overhead). There are a surprising amount of bottlenecks and misconfiguration that can tank performance of networked systems, particularly DBs.
Like you suggest, the reason for not picking SQLite is not reliability, speed, etc. Networked DBs allow decoupling between app and db servers, which have operationally different characteristics. But most importantly, you can have multiple apps access the same DB at the same time. Eg analytics, one off queries, any 3p app that interacts with your data directly.
> You'll note that even Java now recognises that "public static void main(String[] args)" was pointless ceremony.
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.
For fully formed humans? Not great, with exceptions where you can target a 2D layer of cells that are covered in fluids. I've seen some people trying this with, say, retinas, where you only need to target some of the cells. And also with intestinal/colorectal linings, where cells reproduce quickly so there's a chance of actually replacing all of the cells eventually. But for most of the body, I don't think anybody has ever been optimistic about CRISPR fixing pathogenic variants.
CRISPR is a great tool, but it doesn't help with delivering gene therapy across the body.
The rare exception: https://en.wikipedia.org/wiki/Clonally_transmissible_cancer
reply