Sorry to hear about your situation. For the game you're shutting down online services for, forgive my nieve question but how much work is it to expose an environment variable called `GAME_SERVER_URL` and then document the API contract it expects on the other end?
Servers have a real cost, nobody is denying that, but I think the people who bought the game should have an option/alternative in case the servers are down.
We looked into it. Hackers got part of the way there so we decided not to make a change. They might be able to do it after the title is fully sunset and the team disbanded.
We basically have to get as much done on a 3/4 month timeline as possible and it isn’t a priority like saving content or refunding gift cards is. Shutting down is a lot of work.
Anything you can add to the knowledge pool is already going to be of immense help for your community reverse engineering in the future. Be it as simple as stuff like "Our in-game chat runs over IRC" for example - that already simplifies that entire part of figuring it out of machine code out once servers are gone. ANY knowledge you can share no matter how small it is always helps when all you have is a binary file and no server to respond to your requests.
> We looked into it. Hackers got part of the way there so we decided not to make a change. They might be able to do it after the title is fully sunset and the team disbanded.
This doesn't actually answer the question about how hard it would be. What's the specific level of effort required, and some amount of why so people can learn from your experience.
> We basically have to get as much done on a 3/4 month timeline as possible and it isn’t a priority like saving content or refunding gift cards is. Shutting down is a lot of work.
I'd rather have a working game then a refund of a gift card. Including if that means I have to stand up my own servers.
The answer is, "not trivial but easy enough that smart players can probably do it."
To each their own on what they want. We obviously can't give everyone everything. Players don't want the game to go away at all. We still talk to players every day and have confidence we are doing the right thing with our limited time.
Is the game p2p or dedicated infra? Best thing you can do is provide the infra files that you can. Doesn't even have to be turn key. Also for the coordinator API service, anything you can provide there as well. Couple those with a configurable base url and the hackers ought to get it the rest of the way
At least part of the answer is this doesn't meet the requirement of the proposed law. You need to actually provide the functionality of the server-side, not just its API.
This is not using an eGPU with macOS, ie you can't run your chrome on macOS with its GPU acceleration coming from this eGPU. This is tunneling that eGPU to a Linux VM.
I was really hoping we'd see some competition to Github, but no, this is competition for the likes of the Conductor App. Disappointed, I must say. I am tired of using and waiting for alternatives of, Github.
The diff view in particular makes me rage. CodeMirror has a demo where they render a million lines. Github starts dying when rendering a couple thousand. There are options like Codeberg but the experience is unfortunately even worse.
I'd like to pretend that inability to render large diffs is a feature. Nobody is going to actually read the multi-thousand line diff; you need to make smaller PRs, or just admit that the diff in that particular view isn't helpful. I doubt that's the actual reasoning, but I can live with it.
I’d install it via cargo anyway and that would build it for arm64.
If the arm64 version was on homebrew (didn’t check if it is but assume not because it’s not mentioned on the page), I’d install it from there rather than from cargo.
I don’t really manually install binaries from GitHub, but it’s nice that the author provides binaries for several platforms for people that do like to install it that way.
Really? That is your response? This is an high quality article from someone who spend a lot of time implementing a cool tool and also sharing the intricate inner workings of it. And your response is, "eh there are no official binaries for my platform". Give them some credit! Be a little more constructive!
> And on top of it, if you develop for native macOS, There’s no official tooling for visual verification. It’s like 95% of development is web and LLM providers care only about that.
Thinking out loud here, but you could make an application that's always running, always has screen sharing permissions, then exposes a lightweight HTTP endpoint on 127.0.0.1 that when read from, gives the latest frame to your agent as a PNG file.
Edit: Hmm, not sure that'd be sufficient, since you'd want to click-around as well.
Maybe a full-on macOS accessibility MCP server? Somebody should build that!
To be able to use ffmpeg with its native network capabilities in a usecase of media servers, where you need to stream your input to it, and then get multiple outputs (think HLS) that are streamed back is not possible at this point in time. HTTP, FTP, SFTP, all have their limitations, some are outright broken for HLS usecases, others wont stream seeking.
I would have very much loved to use the built-in capabilities instead of patching ffmpeg to add a vfs layer and spend a ton of time figuring out the build pipeline once you add all the codecs and hwaccels. I do hope to be able to change this in the future, I've identified several bugs that I intend to submit patches for.
This is not a special case. Everything you mentioned above can actually be achieved using cli. You can create listeners, configure pipelines, and sinks(granted not ergonomic). Sinks can be HTTP post for example, and sources can be tcp listeners + protocols on top. You can also configure the buffering strategies for each pipeline.
- Client makes request to server (which opens a bidirectional network socket)
- Server uses that bidirectional socket, spawns a local patched ffmpeg with vfs-like characteristics
- ffmpeg (using client-server bidrection socket) does input/output operations, treating client filesystem as if it was local
Thus client doesn't need to open any ports, or expose its filesystem in a traditional mounting manner, and one server can handle filesystems & requests of any amount of clients.
Servers have a real cost, nobody is denying that, but I think the people who bought the game should have an option/alternative in case the servers are down.