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.
I know a an accomplished CS professor, ACM fellow, cited in Knuth's TAOCP (as well as being an easter egg!), who still hunt-and-pecks. In fact, hunt-an-pecks incredibly slowly.
While this is a witty reply, most people are working on corporate CRUD apps. For us, I still follow Jeff Atwood's advice from a 2008 blog post: "We Are Typists First, Programmers Second" Ref: https://blog.codinghorror.com/we-are-typists-first-programme...
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.5) Having a compiler in the loop that does things like enforcing type constraints (and in the case if Rust in particular, therefore memory safety guarantees) is really useful both for humans and LLMs.
> 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.
The counter-argument, and one that matches my experience is working at a lower level is actually beneficial for LLMs since they can see the whole picture and don’t have to guess at abstractions.
reply