While true, people should pay attention that WinRT, the technology infrastructure for UWP, nowadays lives in Win32 and is what is powering anything CoPilot+ PC, Windows ML, the Windows Terminal rewrite, new Explorer extensions, updated context menu on Windows 11,....
It is a moving target, Proton is mostly stuck on Windows XP world, before most new APIs started being a mix of COM and WinRT.
Even if that isn't the case, almost no company would bother with GNU/Linux to develop with Win32, instead of Windows, Visual Studio, business as usual.
Not to disagree, but proton has made it quite easy to run games I've previously struggled with. The nice thing is that it works with any binary, not just those you've purchased. Yes, it's wine, but valve has done wonders for its performance and compatibility.
At this point I think it's incumbent on those who defend the American system to provide evidence that their justice system is not pliable with wealth, that it is a meaningful threat to business and not simply an acceptable accounting risk.
How much do pardons go for these days? One to six million?
As Carney put it, the first and most important difference between the USA and Canada is that Canada enjoys the rule of law.
Meta appears to believe this, and so is pushing chatbot integration into private chats on Messenger and WhatsApp; presumably that will be the vector by which they push product advertisements.
This seems to be about hosting an Sqlite database on a static website like GitHub Pages - this can be a great plan, there is also Datasette in a browser now: https://github.com/simonw/datasette-lite
But that's different from how you collect the data in a git repository in the first place - or are you suggesting just putting a Sqlite file in a git repository? If so I can think of one big reason against that.
Yes, I'm suggesting hosting it on GitHub, leveraging their git lfs support. Just treat it like a binary blob and periodically update with a tagged release.
It's not clear if you are suggesting accepting contributions to the SQLite file via PR from people (but accepting contributions is generally the point of why people put these on projects on GitHub).
But if you are I wouldn't recommend it.
PR's won't be able to show diff's. Worse, as soon as multiple people send a PR at once you'll have a really painful merge to resolve, and GitHub's tools won't help you at all. And you can't edit the files in GitHub's web UI.
I recommend one file per record, JSON, YAML, whatever non-binary format you want. But then you get:
* PR's with diff's that show you what's being changed
* Files that technical people can edit directly in GitHub's web editor
* If 2 people make PR's on different records at once it's an easy merge with no conflicts
* If 2 people make PR's on the same record at once ... ok, you might now have a merge conflict to resolve but it's in an easy text file and GitHub UI will let you see what it is.
You can of course then compile these data files into a SQLite file that can be served in a static website nicely - in fact if you see my other comments on this post I have a tool that does this. And on that note, sorry, I've done a few projects in this space so I have views :-)
There is no lock-in. It is normal to have accounts on multiple storefronts, and have multiple storefronts installed on your gaming PC; one can access multiple digital libraries on the same PC!
Steam wins because it provides a superior product for the end-user, not because of lock-in. Games purchased through Steam can be vetted with user reviews, supported with user-created guides and steam input configurations, streamed across devices, shared with family members, and even modded; all within the Steam experience.
Video Game asset and source control retention was _terrible_. Hell, it's still terrible.
Prior to ~2010 we were simply deleting source code and assets for finished projects; either because they weren't owned by the developer due to a publishing deal, or because the developers didn't want to reuse their garbage code. Same follows for assets, often they were owned by the publisher and not the developer, but if the developer did happen to own them they'd rarely see reuse in future projects. And publishers didn't catch on to the value of data retention until remakes started to make serious money.
Wild culture! At almost[1] every (non game) software company I've ever worked, the source code was sacrosanct. If nothing else in the company was backed up, controlled, audited, and kept precious, at least the source code was. The idea of just casually deleting stuff because you think you're done sounds crazy to me as a software practitioner.
I still have backed up copies of the full source code of personal projects that I wrote 25 years ago. These will probably never be deleted until I'm dead.
1: One company I worked for didn't have a clue about managing their source code, and didn't even use source control. They were a hardware manufacturer that just didn't understand or care about software at all. Not what I'd think of when I think a professional game developer.
6 total and they spanned from 2000 to 2001. Just 1 year.
That was fairly typical at the time. It wasn't uncommon for a game publisher to patch their games, it was uncommon for that patching happen too far from the initial release. After all, they wanted their game devs working on something other than the old release. The patches were strictly just a goodwill thing to make sure the game kept selling.
What I really want is a plugin that starts an icecast server with a given song as a root, and continues to stream songs whose albums/artists are within a certain reference distance of the root on discogs/wikipedia/etc.
So if I start on Guzzlemug I'll get some Blood Incantation, but maybe also some Pink Floyd.
Better to consider is the Proton verified count, which has been rocketing upwards.
https://www.protondb.com/
reply