If harness is all that matters, a co-developed harness + model stack + large compute availability advantage + massive distribution advantage with data for post training will win the market.
What would be the point in making SC3? SC2 is free to play, great game, and still barely gets any players. I play against the same 30-40 people every time in ranked.
Congrats!! I remember growing up in Italy and really really wanting to attend Hacker School but couldn’t afford to. It resonated a lot with me and make me want to keep learning; I am sure you are still having that impact on others today, it’s great to see it’s still around!
Final Fantasy, LOTR, Avatar, are some of the best selling sets in the history of Magic. As much as I don't like some of the spiderslop, there is no real argument against printing more of it. The Hobbit set is going to be a complete blowout success.
The argument is that cashing out now destroys the long-term viability of the game ... but WotC will learn that lesson in a few years when the Magic gravy train crashes.
How many more years do you want to wait? I own a store and we have not really seen any dip in attendance. There are definitely lots of older players churning, but lots of new ones being brought in as well. It's clear the game is being Commander-ified and lots of folks who were more interested in constructed / competitive Magic aren't happy, but it doesn't mean the game will die or anything like that.
What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
a great VCS wouldn't require locking or pre-communication; it would simply refuse to even try to merge assets it couldn't deal with, and leave the result of a merge in a state where the user can reasonably address it (in this case, presumably just "yes, use mine" or "no, use the one already in the repo" and perhaps "use mine but rename it").
I don't get it. Now your options are to lose your work, or for somebody else to lose theirs, or, maybe an un-fun manual merge process - and this after you've both done the work! With a per-file lock, on the other hand, you can't start work until you've got the lock, which prevents others from starting work on that file in the meantime.
(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)
We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.
reply