Does a game "run on Linux" when it has 100% feature parity? 90%? 80%? What are you willing to cut? Some performance? A few graphical effects? Multiplayer?
When you look at the details, Linux gaming is not as good as it might seem.
What you sacrifice in feature parity, you gain in user freedom and principle. To me, that is a worthwhile tradeoff. Especially since it's really not that much different at this point. You're not sacrificing much in most cases now. It's really quite remarkable.
I can't remember the last time a game did anything other than run (this is with only trying games that have been documented to work). I think the worst I've had is audio not working in cut scenes in some game, but I don't remember what game it was.
python does EOL releases after 5 years. I guess versions are readily available for downloading and running with uv, but at that point you are on your own.
bash is glue and for me, glue code must survive the passage of time. The moment you use a high-level language for glue code it stops being glue code.
Hard disagree... I find that Deno shebangs and using fixed version dependencies to be REALLY reliable... I mean Deno 3 may come along and some internals may break, but that should have really limited side effects.
Aside: I am somewhat disappointed that the @std guys don't (re)implement some of the bits that are part of Deno or node compatibility in a consistent way, as it would/could/should be more stable over time.
I like Deno/TS slightly more because my package/library and version can be called directly in the script I'm executing, not a separate .csproj file.
It's never the case that only one thing is important.
In the extreme, you surely wouldn't accept a 1 day or even 1 week build time for example? It seems like that could be possible and not hypothetical for a 1 week build since a system could fuzz over candidate compilation, and run load tests and do PGO and deliver something better. But even if runtime performance was so important that you had such a system, it's obvious you wouldn't ever have developer cycles that take a week to compile.
Build time also even does matter for release: if you have a critical bug in production and need to ship the fix, a 1 hour build time can still lose you a lot here. Release build time doesn't matter until it does.
I would strongly suggest that for quick code-first prototypes. The boiler-plate of "load a texture and render to screen" is quite minimal - you could perhaps make a small library for yourself?
It also has no opinions about how you structure your game data. This means you can represent things like a Flappy Bird clone as just a `Vector2`, rather than having to bash a graph of entities in the shape you want.
> The real answer to all this is to use a provider that supports idempotency keys. Then when you can retry the action repeatedly without it actually happening again. My favorite article on this subject: https://brandur.org/idempotency-keys
Turtles all the way down?
Let's say you are the provider that must support idempotency keys? How should it be done?
When you look at the details, Linux gaming is not as good as it might seem.
But I'm still gaming on Linux!
reply